Hi Marcel,


On Tue, Dec 7, 2021 at 8:23 AM Marcel Taeumel <marcel.taeumel at hpi.de> wrote:

> I noticed that the loading times are about 5 times slower than before and
> that the GC runs runs longer. Hmm...
>
> For that 4 MiB file it compares as follows:
>
> BEFORE: '0.867 per second. 1.15 seconds per run. 3.71012 % GC time.'
> AFTER: '0.181 per second. 5.52 seconds per run. 58.18083 % GC time.'
>
> One can notice this slow-down especially in the FileList tool. Maybe we
> can make it faster by avoiding some GC time?
>

It's definitely slower, there's no doubt. As far as I can tell, most of the
slowdown is happening in `LzwGIFDecoder >>
#handleCode:withPreviousCode:on:` , which is a method that deals with the
"meat" of the LZW decompression algorithm. It could be that creating tons
of OrderedCollections in the process of building LZW bit-code "stacks" is
what's slowing things down. Would it be better to use one collection and
then clear it out each time? To be honest, it's been a couple of years
since I had to implement LZW here so I'm not sure what type of data
structure to use etc. What are some good (general) strategies for avoiding
GC time besides the unnecessary creation of extra objects?

Some kind of optimization clearly needs to happen here. In earlier
messages, Christoph supplied a 36MB GIF that was taking ages to decode on
his end. When I tried it on my machine the image would eventually blow up
in memory and crash. I'm still trying to figure out the best way to profile
this sort of thing.

However, I will say that while the old class can decode faster, it is
fundamentally incorrect and cannot read a lot of the complex GIFs that are
more common these days. For example, if you try to open this one
<https://media.giphy.com/media/bzUwzbxcvJ3XQlcnoi/giphy.gif> or this one
<https://media.giphy.com/media/Byq2w1rdk2uXbWxbIx/giphy.gif>, you will
notice that the old AnimatedGIFReadWriter will bug-out with a subscript
bounds error. This is because something about the LZW was not implemented
correctly. (Giphy.com is generally a good source for test images).

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211207/45aff9c4/attachment.html>