this package is slow af !

[ksmoore17]

I can barely wait the 15 minutes it takes for this to cook 300 frames, and I built it! It's like having an ugly baby: you love it with all your heart, but deep down you know that people who download your child are going to wonder why it can't cook 300 frames in 14 minutes.

Some directions for improvement:

• Reimplement the __main__.py functions (cook dir/file) in rust: use pyo3 allow_threads to ignore GIL and cook multiple frames at once. A python parser should probably dump its parsed vars to a rust pyfunction. It is important to get this correct now because it's the most annoying part of the package to write.
• JIT compile or try to define useful numpy ufuncs for cook methods with numba (eh - kind of heavily constrained)
• Call into a rust backend from more ingredients' cook methods like Quantize and Threshold (Sort would benefit and pretty easy)
• Quantize specifically may benefit from being reimplemented with an ndarray and using rayon to parallelize. See Investigate possible performance gains  okaneco/rscolorq#8 that I bothered the author into opening
• Distributed computing like serverless bs - external to this repo see pierogis-bot

[ksmoore17]

As it turns out, pyo3 can't break the GIL. Instead python Process can be used and rust is probably not relevant. I guess that multiprocessing adds some overhead because things need to be serialized or something? I've implemented this in a type I'm calling Kitchen. It has 2 methods, both for using a Chef to cook a ticket to a path; one is asynchronous (uses Process) and the other is synchronous. With this also came a refactor of the whole Chef submodule (now called Kitchen).

All tests are passing and things seem to be working, but I haven't done any for-real testing yet. I also need to come up with some kind of feedback loop where the program decides whether it should create a process for a frame or run on the main process. Probably do something like if frames > 100 run 10 of the frames sync and then 10 frames async and compare the rates, then do the rest of the frames as the winner.

That Process has to be used is somewhat disappointing as the solution isn't as clean as having a pyo3 python type defined in rust that has a python-callable method that runs its own cook on its own rust thread. It also is hard to debug and seems like it will certainly break. With the refactor of the Kitchen submodule, the idea is to make it easy to exchange the Kitchen (or other Kitchen.types) for some other multiprocessing pattern and have everything else still work.