Figure out Performance.
I have more or less been (mostly subconsciously) trying to keep gridfinder faster than linear with respect to the image dimensions. That is the performance is at most O(W+H)
. However right now the width and height are solved independently, combining the two may lead to O(W*H)
behaviour. However the dataset has already been trimmed by the time we get to that point so it probably won't dominate runtime until we start talking about really big images.
So far gridfinder is written in JS. This isn't a huge concern as it is fits nicely with javascript performance. We don't do too much allocations and we run the same code a lot, giving the JIT a good chance to speed us up. However it could be faster, and more productive to work in in Rust complied to webassembly. Faster also means that we can trade off more compute power to getting better results.
Another question is parallelism. Right now gridfinder is just JS and uses a sync API. It is reasonable to run it in a webworker to avoid blocking the UI during computation, however especially for detectGrid
it may make sense to internally parallelize. For example each row and column is independently ranked for how "edgy" it is. This could be trivially parallelized.
Right now I am leaning towards rewriting in Rust. This would make the code much more pleasant to work with, more reliable and allow easy threading. The downsides is that the resulting code would probably be slightly larger. We could also maintain API compatibility for users that don't want or need parallelism although that would result in blocking the module availability on fetching the wasm module for everyone, even async users. This is probably not a huge deal but worth considering. It could also be worked around by adding a separate top-level file for async users.