Creation form from PNG file very slow on Pharo 4 and 5

Fuel all the way down :)

On Sun, Jan 17, 2016 at 5:17 PM, Tudor Girba <[hidden email]> wrote:

Hi,

> On Jan 17, 2016, at 8:27 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>> On 17 Jan 2016, at 19:58, Stephan Eggermont <[hidden email]> wrote:
>>
>> On 16-01-16 13:50, Dimitris Chloupis wrote:
>>> Seems that creating forms and morph from pngs is super slow
>>
>> Put the forms in one fuel file and materialize that
>>
>> Stephan
>
> That is exactly what I showed him in https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slow

That is actually a very cool idea. Thank you both :)

Doru

> The speedup was massive and it was so easy to do.
>
> But the fact remains that the PNG parser itself, being written in pure Pharo, could use a Plugin counterpart, like in the JPG case.
>
> Sven

--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."

--

Mariano
http://marianopeck.wordpress.com

On 18-01-16 10:27, Thierry Goubier wrote:
> Hi Kilon,
>
> Le 17/01/2016 22:25, Dimitris Chloupis a écrit :
>> Fuel is great indeed and very convenient ,will definetly use this
>> approach if I end up dealing with a lot of PNGs and experience some
>> serious delays, but for now, lazy loading with some forking should be
>> enough to make this instantaneous .  I prefer to stick with pngs because
>> it easy to update them and version control them via git and github
>
> I think there is a way to cache your pngs, their creation time, and load
> them only once upon installation of your tool, and update them in memory
> only if they have been changed on disk.
>
> I suspect all media heavy software have tactics to work around the same
> performance issues: multi-resource formats (zip or fuel) and the same
> kind of caching (load only once when installing the software).

Yes, and combining multiple resources in one file to increase the
likelihood that they will be on the same track of a disk instead of on
60 different ones. In web software there is the same problem with
multiple images. The browser doesn't give you many threads to download
them in parallel. If you only get two and have to download 60 images
from the other side of the ocean...
https://css-tricks.com/css-sprites/

Stephan

Interesting what is faster: reading Form from fuel file or reading it from simple BMP file?

2016-01-19 10:31 GMT+01:00 Hilaire <[hidden email]>:

I meant the problem occurs when you migrate the base application to one
version of Pharo to another one, the fuel file need to be upgraded.

Now in the situation of Dimitris this should not be a problem as its
application build script could initialize the newer fuel bitmap file. As
long as there is not user defined fuel files it should be ok.

Hilaire

--
Dr. Geo
http://drgeo.eu

does not work for me on ubuntu it keeps saying that "cannot locate cairo library" even though its installed via

sudo apt-get install libcairo2-dev

By the way just for the fun, I will make a benchmark comparison betweem PNG loader in pharo and SDL in C to see what is the speed difference and dust off my C skills.

On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano <[hidden email]> wrote:

Yesterday I tested creating PNGs from disk using Athens:

[(AthensCairoSurface
        createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png'
        ifFailed: [ ])
        asForm] bench.

That gave me 46k/s … (455k image) which IMO is pretty reasonable :)

Esteban

> On 19 Jan 2016, at 12:34, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>> On 19 Jan 2016, at 12:29, PBKResearch <[hidden email]> wrote:
>>
>> Denis
>>
>> Very interesting. It would be more interesting if you could save your test image as a .png file, and then include reading with PNGReadWriter in your comparison. This would help to confirm or refute the original point made by Dimitris, that reading from .png is particularly slow.
>
> Check the original thread/case, it is slow. Not *very* slow, but slower than the plugin based JPEG reader. That is what we eventually need, a plugin base PNG reader.
>
>> Peter Kenny
>>
>> From: Pharo-users [mailto:[hidden email]] On Behalf Of Denis Kudriashov
>> Sent: 19 January 2016 10:59
>> To: Any question about pharo is welcome <[hidden email]>
>> Subject: Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5
>>
>>
>> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis <[hidden email]>:
>>> most likely fuel, since it stores your live object as is.
>>>
>>> I like fuel but the fact that I may be limited by incompatible versions is a game stopper for me. I am ok with new version between incompatible with old one but there must be some backward compatibility to any format I use. Or else I end up worrying about things I should not be worrying about.
>>
>> You are right. I perform little experiment. Fuel reading is 60% faster than BMP:
>>
>> Smalltalk garbageCollect; garbageCollect.
>> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
>>            s binary.
>> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
>>
>> Smalltalk garbageCollect; garbageCollect.
>> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
>>            s binary.
>> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] benchFor: 2 seconds.
>>
>> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2 milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2 seconds 3 milliseconds. 2,860 per second))"
>
>

$ apt-cache search cairo | grep cairo | less
shows... libcairo2 - Cairo 2D vector graphics library

so following the pattern for Debian here...
http://pharo.org/gnu-linux-installation

I presume...
$ sudo dpkg --add-architecture i386
$ sudo apt-get update
$ sudo apt-get install  libcairo2:i386

...but haven't tried this since I'm using 32-bit Debian.

cheers -ben

On Tue, Jan 19, 2016 at 9:02 PM, Dimitris Chloupis
<[hidden email]> wrote:
> ah yes it needs the 32 bit libs of cairo, yeah good luck with that, cant
> wait till we finally support 64 bit, but far my most needed feature of
> pharo. No idea how to find 32 bit lib of cairo, google returns nothing
> meaningful, download page of cairo website mentions nothing.
>
> On Tue, Jan 19, 2016 at 2:52 PM Dimitris Chloupis <[hidden email]>
> wrote:
>>
>> does not work for me on ubuntu it keeps saying that "cannot locate cairo
>> library" even though its installed via
>>
>> sudo apt-get install libcairo2-dev
>>
>> By the way just for the fun, I will make a benchmark comparison betweem
>> PNG loader in pharo and SDL in C to see what is the speed difference and
>> dust off my C skills.
>>
>> On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano <[hidden email]>
>> wrote:
>>>
>>> Yesterday I tested creating PNGs from disk using Athens:
>>>
>>> [(AthensCairoSurface
>>>         createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png'
>>>         ifFailed: [ ])
>>>         asForm] bench.
>>>
>>> That gave me 46k/s … (455k image) which IMO is pretty reasonable :)
>>>
>>> Esteban
>>>
>>> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe <[hidden email]> wrote:
>>> >
>>> >
>>> >> On 19 Jan 2016, at 12:29, PBKResearch <[hidden email]> wrote:
>>> >>
>>> >> Denis
>>> >>
>>> >> Very interesting. It would be more interesting if you could save your
>>> >> test image as a .png file, and then include reading with PNGReadWriter in
>>> >> your comparison. This would help to confirm or refute the original point
>>> >> made by Dimitris, that reading from .png is particularly slow.
>>> >
>>> > Check the original thread/case, it is slow. Not *very* slow, but slower
>>> > than the plugin based JPEG reader. That is what we eventually need, a plugin
>>> > base PNG reader.
>>> >
>>> >> Peter Kenny
>>> >>
>>> >> From: Pharo-users [mailto:[hidden email]] On
>>> >> Behalf Of Denis Kudriashov
>>> >> Sent: 19 January 2016 10:59
>>> >> To: Any question about pharo is welcome <[hidden email]>
>>> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on
>>> >> Pharo 4 and 5
>>> >>
>>> >>
>>> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis <[hidden email]>:
>>> >>> most likely fuel, since it stores your live object as is.
>>> >>>
>>> >>> I like fuel but the fact that I may be limited by incompatible
>>> >>> versions is a game stopper for me. I am ok with new version between
>>> >>> incompatible with old one but there must be some backward compatibility to
>>> >>> any format I use. Or else I end up worrying about things I should not be
>>> >>> worrying about.
>>> >>
>>> >> You are right. I perform little experiment. Fuel reading is 60% faster
>>> >> than BMP:
>>> >>
>>> >> Smalltalk garbageCollect; garbageCollect.
>>> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
>>> >>            s binary.
>>> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds.
>>> >>
>>> >> Smalltalk garbageCollect; garbageCollect.
>>> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
>>> >>            s binary.
>>> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]]
>>> >> benchFor: 2 seconds.
>>> >>
>>> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2
>>> >> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2
>>> >> seconds 3 milliseconds. 2,860 per second))"
>>> >
>>> >
>>>
>>>
>