On Jun 27, 2020, at 8:30 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > Just because the bulk of the time is in the decode doesn’t mean the decode is > inefficient or can be improved upon. It might be the most expensive stage in > the process regardless of the implementation.
This is I think the most important point; image decoding is an expensive operation, and it makes sense that the bulk of your time decoding is spent on it. The question is how it stacks up to other decoders; if you're able to write a quick C proof-of-concept to test how fast libpng does it (or libspng) and run the same benchmarks, you'll get your answer there. Depending on how regular your images are (size-wise, especially), you may be able to get some additional mileage out of pooling your receiving buffers and reusing them after your operations are complete. There doesn't appear to be a handle for that in the current image/png library like there is for encoding, though; you'd have to do some surgery on decoder.readImagePass to do something like that. - Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5F296DCC-1521-4D04-9D93-9BCEB6B5B537%40gmail.com.
