1 person found this helpful
Great idea Sean! I would support this request to improve working.
I actually did some more testing of this this afternoon, and I found that some of my above numbers are off:
I still get 1 core of saturated CPU usage, but my write speeds are actually only ~15% of my write capacity (arguably 7%, but that's comparing to artificial benchmarks and not 'real' work).
I also wasn't kidding about how much my masks benefit from compression - 1.8GB down to 500MB - I'd like to say that's no big deal over the long term... but I'd be lying given the direction sensor densities are still going.
We've been working on that. But it is a lot harder to get right than it sounds.
Actually, it doesn't sound easy at all - if all the layers were raster, sure. If the layers could be written out of order, sure.
But queing the layers based on an accurate prediction of their compression time to minimize the write waits and retain layer order - that has to be a PITA. I'm sure chunking data to the different cores could achieve some gains, but at the cost of the overhead and a far less elegant (and future-proof) solution.
I'm ecstatic that it's being worked on, though, and look forward to it whenever it debuts.
You left out: making sure the ZIP library really is thread safe, along with all code that MIGHT EVER be called when setting up a layer to be saved.