Re: Image transforms as a benchmark?

[Arthur Miller <arthur.miller@live.com>]

Alan Third <alan@idiocy.org> writes:

> On Sun, Sep 12, 2021 at 03:28:09PM +0200, Arthur Miller wrote:
>> Alan Third <alan@idiocy.org> writes:
>> 
>> > On Sun, Sep 12, 2021 at 01:45:39PM +0200, Arthur Miller wrote:
>> >> 
>> >> I tried to make another little benchmark, I saw with optimization flags, that
>> >> quite some loops have got unrolled and vectorized in image.c, so I wanted to see
>> >> if it matters when doing some transforms on images. I tested so far just with
>> >> svg.
>> >> 
>> >> I wonder if image-rotate is handled completely by external libraries? I see
>> >> no effect on performance, regardless of how many time I rotate some image. Is it
>> >> same situation for scaling down? I see big difference when scaling up images so
>> >> I guess that is handled by Emacs own code?
>> >
>> > SVG is probably not a great example for testing image transforms, at
>> > least if you're using the master branch.
>> 
>> I wanted to make few benchmarks that are relevant to normal use. I do some
>> searches, replacements and similar in a big text buffer (Plat's dialoagues as I
>> posted a day before), and I did some symbol lookups in Emacs lisp sources. SVG
>> is getting a bit of uprise lately, so thought it might matter. But I'll guess
>> I'll skip SVG then.
>
> Well, don't let me put you off if you're bench-marking things that
> actually matter. I assumed it was a purely intellectual exercise.
Yes, but it's no idea to measure wrong thing either :).

>> > Image scaling in SVG is handled at the time the image is rasterized,
>> > so if you ask for the image to be doubled in size, the rasterizer
>> > creates a bitmap that is twice the size.
>> 
>> Yes, I saw the code. But I wasn't sure if it does upscaling itself, or it
>> outsources the entire venture to librsvg & co. I understand the most of image
>> operations are handled by 3rd party libraries. I saw some code for image
>> transforms in image.c, but I haven't looked much where it is used and so, maybe
>> I should have :).
>> 
>> Why is it so drammatic difference then when scaling up compared to scaling down?
>> It takes like 5 seconds to do that loop in scale-up test, but just a fraction of
>> a second when scaling down. I tested little different versions, and I see the
>> effect, so scaling is done.
>
> I have no idea. Both scaling up and down are performed by librsvg
> itself. It may be some side-effect of the way we do the scaling, with
> the wrapped SVG, but I don't have enough knowledge of librsvg to know
> why.
>
> Alternatively we're doing something wrong that I haven't noticed.
>
> Is it possible to use a profiler to find out which calls are slow?
It probably is, you are correct :). I haven't tried; I should have. When I am
done with some benchmarks, I can take a peek.

Thanks for the help!