Optimize Schematic.Deserialize, a lot

[dsharlet]

This may work around the issue raised in #187. Schematic.Deserialize should be orders of magnitude faster with this branch.

The problem is when deserializing a circuit, the components and wires would be added as if they were added manually in the UI, rebuilding the nodes one at a time. The ConnectedTo algorithm was also quadratic. So I think the old behavior was two quadratic algorithms nested inside each other. How embarrassing :)

[Federerer]

From over 3.2 seconds to around 30 milliseconds, that's really a lot 😉 I remember looking at this, when I've been testing why move tool is so slow. This however, will still be a problem, as the move tool generates an event for every element. Using some kind of debounce there helps a lot, but I didn't wanted to add a dependency on System.Reactive in Circuit library, because it's quite heavy and introduces a lot of unwanted dependencies in netstandard projects, see: dotnet/reactive#1847 so we might need to implement something just for this use-case.

[dsharlet]

Yeah, I was thinking about that too. I think that is fixable also by batching the node rebuilds, just kinda annoying to actually implement somehow. I started down that route before just adding a special case for the constructor, but we should probably just do both.

[dsharlet]

Enabling batching is actually a massive headache because of the way I designed all this. I'm now just trying to optimize everything that happens while moving a large selection around. I think it should be possible to make it much faster.

[Federerer]

Enabling batching is actually a massive headache because of the way I designed all this.

I know, I've tried doing it this way and gave up. Can't remember though why I dropped this concept and switched to debounce 🤔

[dsharlet]

Well, I wouldn't say moving around a lot of elements at once is fast now, but it's a lot better than it was. I can move around a large circuit all at once, and it at least feels pretty responsive, but it still makes my CPU fan go nuts :)

[dsharlet]

I think at this point there isn't much room for optimization without major design refactoring. There's basically just one major issue left, that we have to reconnect all terminals whenever a wire moves. Batching wire moves would of course make this better, but fixing either of these issues is probably more trouble than it's worth. Moving an entire large circuit around at least doesn't feel really laggy any more.

[dsharlet]

I was mistaken, this is now legitimately fast. According to the profiler, now more time is spent in WPF drawing and such, than schematic manipulation. I had been trying to use bounding boxes to optimize this the whole time, but it turns out there was a boneheaded bug in that code. Fixing that makes it work as expected.

[dsharlet]

It's quite likely this is introducing some bugs. I've found and fixed a few (including a few old ones from before this change), but I'm just going to merge it and keep working on and testing other things.

[Federerer]

Nice 😁 I'll check this tomorrow.