<div dir="ltr"><div dir="ltr"><div>Hi Marcel,</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 7, 2021 at 8:23 AM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_495083338080756458__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">I noticed that the loading times are about 5 times slower than before and that the GC runs runs longer. Hmm...<div><br></div><div>For that 4 MiB file it compares as follows:</div><div><br></div><div><div><span style="font-size:13.3333px">BEFORE: '0.867 per second. 1.15 seconds per run. 3.71012 % GC time.' </span></div><div><span style="font-size:13.3333px">AFTER: '0.181 per second. 5.52 seconds per run. 58.18083 % GC time.' </span></div></div><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">One can notice this slow-down especially in the FileList tool. Maybe we can make it faster by avoiding some GC time?</span></div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>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.<br></div><div>  <br></div><div>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 <a href="https://media.giphy.com/media/bzUwzbxcvJ3XQlcnoi/giphy.gif">this one</a> or <a href="https://media.giphy.com/media/Byq2w1rdk2uXbWxbIx/giphy.gif">this one</a>, 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).<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Eric</div></div></div></div>