Debulk Drivers

[DavJCosby]

Just finished #65, now onto trimming down this massive struct.

Right now, a default Driver struct takes up a whopping 3536 bytes. Here's the breakdown:

Name	Type	Size	% of Total
buffers	BufferContainer	2440 bytes	89.4%
sled	Option<Sled>	144 bytes	5.3%
filters	Filters	48 bytes	1.8%
startup_commands	StartupCommands	16 bytes	0.6%
compute_commands	ComputeCommands	16 bytes	0.6%
draw_commands	DrawCommands	16 bytes	0.6%
startup	Instant	16 bytes	0.6%
last_update	Instant	16 bytes	0.6%

So biggest priority is definitely going to be shrinking BuffersContainer.

Why BufferContainer so big?

I did some cursed stuff in the name of performance. A buffer container is a collection of no-heap HashMaps that contain no-heap vectors. Looking back on that, kinda a dumb decision but we'll use our benchmarks to see how dumb.

[DavJCosby]

Shrinking BufferContainer

Just dropping benchmark results for a handful of solutions. The ripples example makes solid use of buffers, so I'll be focusing in on that.

Control (No Change)

ripples-nochange                time:   [20.551 ms 22.261 ms 23.739 ms]
ripples-heapvec                 time:   [19.896 ms 22.316 ms 24.722 ms]
ripples-heapmapandvec           time:   [22.252 ms 24.240 ms 26.305 ms]

Yeah okay it's settled. We'll be getting rid of the heapless hashmap and just use a normal vec. There's no real performance benefit and we get to shrink our dependency list and remove our buffer ceilings.

While we're at it, I'm taking the heapless map out of filter as well.

Now, when I run size_of::<Driver>(), I get 512. Much better.

[DavJCosby]

closed by #68