[squeak-dev] [Discussion] GIF and Animated GIF Refactoring

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sun Nov 28 20:10:26 UTC 2021


Hi Eric,


thanks for the reply. Of course, every test will be very valuable!


Regarding efficiency and optimization: There are other people who might be able to give you detailed information, but maybe I can add a few basic notes:


> I am very likely using inappropriate classes or data structures for some of the decoding.


Hypothetically any subclass of RawBitsArray (maybe even create a new one?) could be your friend (this hierarchy has been reworked recently, so maybe it takes some time to find the right structure.)


> Worse case scenario: we offload the encoding/decoding of LZW data to a plugin.

Or use FFI instead. But whenever possible, I would myself prefer a transparent implementation inside the image.

> That said, are there other packages available for profiling etc, or is MessageTally class >> spyOn: the bread and butter for that kind of thing?

There is the InteractiveProfilingTool <https://github.com/hpi-swa-teaching/InteractiveProfilingTool> which aggregates the recorded data a bit more conveniently, or you could evaluate the following: [self doSomeOperation] timeProfile. But it's not a completely new approach, just some slight refinements.
Apart from that, we have SpaceTally for measuring object sizes (see the class comment), but I have not yet used it myself.
If you want to analyze the usage of different VM primitives and modules, you could try out my new BenchmarkSimulator from SimulationStudio <https://github.com/LinqLover/SimulationStudio> (experimental), but it is itself very slow.

> On a related note, I did notice that during GIF frame composition there was what seemed to me a lot of time spent on symbol/string comparison at one point. (`9.5% {192ms} ByteSymbol(Symbol)>>=`). I don't quite understand why that should be the case.

For symbols, you can use #== instead which is compiled as an inlined message send (-> faster).

Have a nice weekend!

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eric Gade <eric.gade at gmail.com>
Gesendet: Sonntag, 28. November 2021 17:31:17
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Discussion] GIF and Animated GIF Refactoring

Hi Christoph,

On Sat, Nov 27, 2021 at 2:12 PM Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> wrote:

  *   compatibility checks - are there any breaking changes in terms of behavior, or has the public protocol been changed? Maybe it would be worth improving compatibility, adding a few "deprecated" methods, autc. For instance, probably we should re-add an empty subclass AnimatedGIFReadWriter in the 60Deprecated/61Deprecated package to not break existing code that relies on it. Another example, #openGIFInWindow:/#fromStream: are not understood by BetterAnimatedImageMorph class.

I agree. None of this replacement should happen without preserving that polymorphism, at least for the time being. I should probably write a few tests along the way (I have only a handful from previous ports)


  *   code review - not sure whether there is anyone who would like to have a detailed look at your patch before it is integrated. But as you say it is "tested by the crowd" on two different Smalltalk systems, my personal opinion would be that this should not be a reason to block great contributions.

I believe I have some tests in ports to the other Smalltalks but I'll probably have to refactor them. In particular, there is and should be a test for reading a GIF, writing it out, reading it back in, and having the correct pixels at expected locations.

PS: Have you or someone else already tried to optimize the new GIFReadWriter for performance? I am having a 36 MB large GIF<https://github.com/LinqLover/TelegramSmalltalkBot/blob/master/img/screencast.gif> here which takes eternities (> 10 minutes) to file in on my machine. With a 9 MB small GIF, it still takes a few minutes. And the RAM consumption of my image is noticeably high. But after that, I can play the GIF with ca. 25 FPS. However, the old implementation was not faster either.

It's actually worse than you think -- I cannot spy on the process of parsing your large GIF file without my Squeak process eventually killing itself, probably due to memory consumption. As it stands, I don't know the exact reason the memory consumption is so high. There *must* be some places for optimization in the decoding. When I rewrote the LZW encoding/decoding portions of this, my immediate goal was to understand what was going on -- therefore being verbose and using more objects. I am very likely using inappropriate classes or data structures for some of the decoding. Worse case scenario: we offload the encoding/decoding of LZW data to a plugin.

There is also the matter of working with the Bitmap and Form objects at a low level, which I must admit I still don't fully grasp. I could be missing something there.

That said, are there other packages available for profiling etc, or is MessageTally class >> spyOn: the bread and butter for that kind of thing?

On a related note, I did notice that during GIF frame composition there was what seemed to me a lot of time spent on symbol/string comparison at one point. (`9.5% {192ms} ByteSymbol(Symbol)>>=`). I don't quite understand why that should be the case.


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


More information about the Squeak-dev mailing list