Discussion:
Creation form from PNG file very slow on Pharo 4 and 5
(too old to reply)
Dimitris Chloupis
2016-01-16 12:50:21 UTC
Permalink
Seems that creating forms and morph from pngs is super slow

opened bug report

https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slow
Nicolai Hess
2016-01-16 13:40:43 UTC
Permalink
Post by Dimitris Chloupis
Seems that creating forms and morph from pngs is super slow
opened bug report
https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slow
your are loading 0-59 images in one turn. this takes ~ 1000 ms. Thats not
bad.

How about loading them only on demand? This may cut down the start up time:

attache a small change for get and put the images into a dictionary and
only load new
"xx seconds-image" when it is used for the first time.

- > [ChronosManager open] timeToRun
"0:00:00:00.626"
Dimitris Chloupis
2016-01-16 13:48:24 UTC
Permalink
sorry but thats plain horrible performance wise and those images are needed
as soon as the gui is opened. So there can be no lazy loading for them. The
total size for all the 60 images is 530kbs . What would happen if I did
some serious animations of 10s of mbs , I will have to go to buy a coffee
to get my GUI opened :D
Post by Nicolai Hess
Post by Dimitris Chloupis
Seems that creating forms and morph from pngs is super slow
opened bug report
https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slow
your are loading 0-59 images in one turn. this takes ~ 1000 ms. Thats not
bad.
attache a small change for get and put the images into a dictionary and
only load new
"xx seconds-image" when it is used for the first time.
- > [ChronosManager open] timeToRun
"0:00:00:00.626"
Denis Kudriashov
2016-01-16 14:05:30 UTC
Permalink
Hi.

I am not understand why you need to load images on startup? Why you not
save pharo image with preloaded png files?
With that case you will get immediate startup with ready to use forms.

Best regards,
Denis
16 яМв. 2016 г. 14:50 пПльзПватель "Dimitris Chloupis" <
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading for
them. The total size for all the 60 images is 530kbs . What would happen if
I did some serious animations of 10s of mbs , I will have to go to buy a
coffee to get my GUI opened :D
Post by Nicolai Hess
Post by Dimitris Chloupis
Seems that creating forms and morph from pngs is super slow
opened bug report
https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slow
your are loading 0-59 images in one turn. this takes ~ 1000 ms. Thats not
bad.
attache a small change for get and put the images into a dictionary and
only load new
"xx seconds-image" when it is used for the first time.
- > [ChronosManager open] timeToRun
"0:00:00:00.626"
Dimitris Chloupis
2016-01-16 14:30:10 UTC
Permalink
Images are needed on startup when the project is updated which means any of
the image files could change.

Its a big problem for me , I can preload everything, save it to an image
and distribute the image instead with zero delays. I dont care if this is
going to be improved or not , since I can work around this limitation.

I was merely reporting the creating forms from pngs is too slow.
Post by Denis Kudriashov
Hi.
I am not understand why you need to load images on startup? Why you not
save pharo image with preloaded png files?
With that case you will get immediate startup with ready to use forms.
Best regards,
Denis
16 яМв. 2016 г. 14:50 пПльзПватель "Dimitris Chloupis" <
sorry but thats plain horrible performance wise and those images are
Post by Dimitris Chloupis
needed as soon as the gui is opened. So there can be no lazy loading for
them. The total size for all the 60 images is 530kbs . What would happen if
I did some serious animations of 10s of mbs , I will have to go to buy a
coffee to get my GUI opened :D
Post by Nicolai Hess
Post by Dimitris Chloupis
Seems that creating forms and morph from pngs is super slow
opened bug report
https://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slow
your are loading 0-59 images in one turn. this takes ~ 1000 ms. Thats
not bad.
attache a small change for get and put the images into a dictionary and
only load new
"xx seconds-image" when it is used for the first time.
- > [ChronosManager open] timeToRun
"0:00:00:00.626"
Denis Kudriashov
2016-01-16 23:07:53 UTC
Permalink
Post by Dimitris Chloupis
Images are needed on startup when the project is updated which means any
of the image files could change.
Its a big problem for me , I can preload everything, save it to an image
and distribute the image instead with zero delays. I dont care if this is
going to be improved or not , since I can work around this limitation.
I was merely reporting the creating forms from pngs is too slow.
Years ago I investigate this kind of problem for my application. I can't
optimize PNGReader on image side. I tried to connect some C library but no
success.
My time was limited for this issue. And it was not really critical for me.
So I gave up.

After that Athens was announced. And as I understand Cairo can work with
png-files directly without loading it to image side. I not try it. Maybe
you can experiment with this.
Stephan Eggermont
2016-01-16 14:01:58 UTC
Permalink
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading for
them. The total size for all the 60 images is 530kbs . What would happen
if I did some serious animations of 10s of mbs , I will have to go to
buy a coffee to get my GUI opened :D
Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.

Stephan
Dimitris Chloupis
2016-01-16 14:40:31 UTC
Permalink
disk, 1TB. why it matters ? from my profile its clear that its not the
primitive that is the problem but how Pharo processes pngs.

I happen to work with a lot of big data both in 3d graphics, a blender file
can easily reach 250 mb and it opens under a second and audio files , plus
instrument that uses alot of audio files as samples of several gbs giving
again instanenous loading. I am not talking here 60 files, I am talking
thousands of files.

I report a sever limitation and I have been told

a) I have not done enough to isolate the problem when I post clear
profiling reports and the code that is responsible for it
b) why I make a fuss about it since there are work arounds
c) that its a hardware limitation when the hardware is able to perform
light years ahead of what pharo is currently doing

Sorry but this kind of attitude is really bad, when someone reports a bug I
find it a lot better to tell him that you don't care or not reply at all
and ignore him than just find excuses for the bug or limitation.

I see it every single time I complain about a problem there is a few people
who are logical about this like Ben , Esteban etc and then some other that
in complete denial zone and easily offended by the truth.
Post by Stephan Eggermont
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading for
them. The total size for all the 60 images is 530kbs . What would happen
if I did some serious animations of 10s of mbs , I will have to go to
buy a coffee to get my GUI opened :D
Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.
Stephan
Dimitris Chloupis
2016-01-16 14:47:31 UTC
Permalink
in any case, ignore my bug reports, I am done with this, I waste my time
and your time . Its clear pharo is not really suited for my needs, life
goes on.
Post by Dimitris Chloupis
disk, 1TB. why it matters ? from my profile its clear that its not the
primitive that is the problem but how Pharo processes pngs.
I happen to work with a lot of big data both in 3d graphics, a blender
file can easily reach 250 mb and it opens under a second and audio files ,
plus instrument that uses alot of audio files as samples of several gbs
giving again instanenous loading. I am not talking here 60 files, I am
talking thousands of files.
I report a sever limitation and I have been told
a) I have not done enough to isolate the problem when I post clear
profiling reports and the code that is responsible for it
b) why I make a fuss about it since there are work arounds
c) that its a hardware limitation when the hardware is able to perform
light years ahead of what pharo is currently doing
Sorry but this kind of attitude is really bad, when someone reports a bug
I find it a lot better to tell him that you don't care or not reply at all
and ignore him than just find excuses for the bug or limitation.
I see it every single time I complain about a problem there is a few
people who are logical about this like Ben , Esteban etc and then some
other that in complete denial zone and easily offended by the truth.
Post by Stephan Eggermont
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading for
them. The total size for all the 60 images is 530kbs . What would happen
if I did some serious animations of 10s of mbs , I will have to go to
buy a coffee to get my GUI opened :D
Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.
Stephan
Esteban Lorenzano
2016-01-16 15:48:20 UTC
Permalink
Hi Kilon,

I’m sorry to feel you frustrated.
Is clear than morphic (and the world) as it is now is not well suited to the kind of development you want to do, and clearly documentation is not good enough (even if we have moved forward recently, in part with your collaboration)

Anyway, yes, using the world as is and morphic are not very suitable to hard consuming graphics, but there are works that have been happening that improves all that:

Using not the world, but SDL2 (through OS-Window) will reduce the cpu consumption drastically
 in fact, what happens now (as far as I can guess
 since I don’t know your stuff) is not that instancing a png is slow, but the rendering (you are redrawing every time and that is not optimised in morphic, who takes area as damaged every time and redraws it
 using athens, who is vectorial and then consuming).
So, with SDL2 you will improve (and you will have separated windows).
Also, I think you do 3d stuff so in your case I would explore wooden
 I remember Ronnie showed me an animated scene (I think it was the water example) with more then 200 fps without much effort.
Finally
 I know about people doing animations with Pharo (and morphic) than have a lot better performance than you had
 so there is clearly a problem there. If you give me your sources I can give them a look and try to figure out what is happening.

So well
 I think is not that is not possible, but that you are traveling paths that are new for us, then not documented (or even tested), or really optimised.
Something that we are willing to improve, as always :)

cheers!
Esteban
in any case, ignore my bug reports, I am done with this, I waste my time and your time . Its clear pharo is not really suited for my needs, life goes on.
disk, 1TB. why it matters ? from my profile its clear that its not the primitive that is the problem but how Pharo processes pngs.
I happen to work with a lot of big data both in 3d graphics, a blender file can easily reach 250 mb and it opens under a second and audio files , plus instrument that uses alot of audio files as samples of several gbs giving again instanenous loading. I am not talking here 60 files, I am talking thousands of files.
I report a sever limitation and I have been told
a) I have not done enough to isolate the problem when I post clear profiling reports and the code that is responsible for it
b) why I make a fuss about it since there are work arounds
c) that its a hardware limitation when the hardware is able to perform light years ahead of what pharo is currently doing
Sorry but this kind of attitude is really bad, when someone reports a bug I find it a lot better to tell him that you don't care or not reply at all and ignore him than just find excuses for the bug or limitation.
I see it every single time I complain about a problem there is a few people who are logical about this like Ben , Esteban etc and then some other that in complete denial zone and easily offended by the truth.
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading for
them. The total size for all the 60 images is 530kbs . What would happen
if I did some serious animations of 10s of mbs , I will have to go to
buy a coffee to get my GUI opened :D
Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.
Stephan
Dimitris Chloupis
2016-01-16 16:17:39 UTC
Permalink
This post might be inappropriate. Click to display it.
Esteban Lorenzano
2016-01-16 16:23:08 UTC
Permalink
Post by Dimitris Chloupis
Thanks Estaban as I said I am not giving up on Pharo.
I am actually very interested making pharo work with Unreal to give Pharo access to the most powerful graphics engine out there. Yeap moving to SDL could help a lot, I am 100% behind this idea.
Definetly will keep using Pharo but I will try to integrate with powerful existing technology , so maybe I can bring something new to Pharo too , its not a suprise that Morphic is not up to my demands, these things take a lot of coders and resources that pharo does not have. Like you I believe in leveraging existing technologies from inside Pharo like SDL.
If I am able to build Unreal Engine with a minimal Pharo API as a DLL and use your FFI to control it, I think I will have the best of both world. I will have to experiment and see :)
btw
 I think joining unreal with pharo can give us a lot of power :)
Also this something already done by Goran at 3dicc (http://www.3dicc.com) 
 I think his work is closed but Goran has always been very helpful and offered guidelines, etc. (I wanted to do the Unreal-Pharo bridge myself but well
 no time so I stopped) :D

I think if you are serious in your attempt I can put both of you in contact...

cheers,
Esteban
Post by Dimitris Chloupis
Hi Kilon,
I’m sorry to feel you frustrated.
Is clear than morphic (and the world) as it is now is not well suited to the kind of development you want to do, and clearly documentation is not good enough (even if we have moved forward recently, in part with your collaboration)

Using not the world, but SDL2 (through OS-Window) will reduce the cpu consumption drastically
 in fact, what happens now (as far as I can guess
 since I don’t know your stuff) is not that instancing a png is slow, but the rendering (you are redrawing every time and that is not optimised in morphic, who takes area as damaged every time and redraws it
 using athens, who is vectorial and then consuming).
So, with SDL2 you will improve (and you will have separated windows).
Also, I think you do 3d stuff so in your case I would explore wooden
 I remember Ronnie showed me an animated scene (I think it was the water example) with more then 200 fps without much effort.
Finally
 I know about people doing animations with Pharo (and morphic) than have a lot better performance than you had
 so there is clearly a problem there. If you give me your sources I can give them a look and try to figure out what is happening.
So well
 I think is not that is not possible, but that you are traveling paths that are new for us, then not documented (or even tested), or really optimised.
Something that we are willing to improve, as always :)
cheers!
Esteban
in any case, ignore my bug reports, I am done with this, I waste my time and your time . Its clear pharo is not really suited for my needs, life goes on.
disk, 1TB. why it matters ? from my profile its clear that its not the primitive that is the problem but how Pharo processes pngs.
I happen to work with a lot of big data both in 3d graphics, a blender file can easily reach 250 mb and it opens under a second and audio files , plus instrument that uses alot of audio files as samples of several gbs giving again instanenous loading. I am not talking here 60 files, I am talking thousands of files.
I report a sever limitation and I have been told
a) I have not done enough to isolate the problem when I post clear profiling reports and the code that is responsible for it
b) why I make a fuss about it since there are work arounds
c) that its a hardware limitation when the hardware is able to perform light years ahead of what pharo is currently doing
Sorry but this kind of attitude is really bad, when someone reports a bug I find it a lot better to tell him that you don't care or not reply at all and ignore him than just find excuses for the bug or limitation.
I see it every single time I complain about a problem there is a few people who are logical about this like Ben , Esteban etc and then some other that in complete denial zone and easily offended by the truth.
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading for
them. The total size for all the 60 images is 530kbs . What would happen
if I did some serious animations of 10s of mbs , I will have to go to
buy a coffee to get my GUI opened :D
Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.
Stephan
Dimitris Chloupis
2016-01-16 16:29:55 UTC
Permalink
yes Goran introduced me to the Nim language that compiles to C and they
hired the creator of it to work for their company , Goran made a squeak (it
also works with pharo) to nim bridge . But I was not aware of him using
Unreal. Definetely will send him a message . Will keep you posted on my
progress, Unreal is definitely coming to Pharo :)
Post by Dimitris Chloupis
Thanks Estaban as I said I am not giving up on Pharo.
I am actually very interested making pharo work with Unreal to give Pharo
access to the most powerful graphics engine out there. Yeap moving to SDL
could help a lot, I am 100% behind this idea.
Definetly will keep using Pharo but I will try to integrate with powerful
existing technology , so maybe I can bring something new to Pharo too , its
not a suprise that Morphic is not up to my demands, these things take a lot
of coders and resources that pharo does not have. Like you I believe in
leveraging existing technologies from inside Pharo like SDL.
If I am able to build Unreal Engine with a minimal Pharo API as a DLL and
use your FFI to control it, I think I will have the best of both world. I
will have to experiment and see :)
btw
 I think joining unreal with pharo can give us a lot of power :)
Also this something already done by Goran at 3dicc (http://www.3dicc.com)

 I think his work is closed but Goran has always been very helpful and
offered guidelines, etc. (I wanted to do the Unreal-Pharo bridge myself but
well
 no time so I stopped) :D
I think if you are serious in your attempt I can put both of you in contact...
cheers,
Esteban
Post by Esteban Lorenzano
Hi Kilon,
I’m sorry to feel you frustrated.
Is clear than morphic (and the world) as it is now is not well suited to
the kind of development you want to do, and clearly documentation is not
good enough (even if we have moved forward recently, in part with your
collaboration)

Anyway, yes, using the world as is and morphic are not very suitable to
hard consuming graphics, but there are works that have been happening that
Using not the world, but SDL2 (through OS-Window) will reduce the cpu
consumption drastically
 in fact, what happens now (as far as I can guess

since I don’t know your stuff) is not that instancing a png is slow, but
the rendering (you are redrawing every time and that is not optimised in
morphic, who takes area as damaged every time and redraws it
 using athens,
who is vectorial and then consuming).
So, with SDL2 you will improve (and you will have separated windows).
Also, I think you do 3d stuff so in your case I would explore wooden
 I
remember Ronnie showed me an animated scene (I think it was the water
example) with more then 200 fps without much effort.
Finally
 I know about people doing animations with Pharo (and morphic)
than have a lot better performance than you had
 so there is clearly a
problem there. If you give me your sources I can give them a look and try
to figure out what is happening.
So well
 I think is not that is not possible, but that you are traveling
paths that are new for us, then not documented (or even tested), or really
optimised.
Something that we are willing to improve, as always :)
cheers!
Esteban
in any case, ignore my bug reports, I am done with this, I waste my time
and your time . Its clear pharo is not really suited for my needs, life
goes on.
Post by Dimitris Chloupis
disk, 1TB. why it matters ? from my profile its clear that its not the
primitive that is the problem but how Pharo processes pngs.
I happen to work with a lot of big data both in 3d graphics, a blender
file can easily reach 250 mb and it opens under a second and audio files ,
plus instrument that uses alot of audio files as samples of several gbs
giving again instanenous loading. I am not talking here 60 files, I am
talking thousands of files.
I report a sever limitation and I have been told
a) I have not done enough to isolate the problem when I post clear
profiling reports and the code that is responsible for it
b) why I make a fuss about it since there are work arounds
c) that its a hardware limitation when the hardware is able to perform
light years ahead of what pharo is currently doing
Sorry but this kind of attitude is really bad, when someone reports a
bug I find it a lot better to tell him that you don't care or not reply at
all and ignore him than just find excuses for the bug or limitation.
I see it every single time I complain about a problem there is a few
people who are logical about this like Ben , Esteban etc and then some
other that in complete denial zone and easily offended by the truth.
Post by Dimitris Chloupis
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading
for
Post by Dimitris Chloupis
them. The total size for all the 60 images is 530kbs . What would
happen
Post by Dimitris Chloupis
if I did some serious animations of 10s of mbs , I will have to go to
buy a coffee to get my GUI opened :D
Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.
Stephan
Nicolai Hess
2016-01-16 19:50:46 UTC
Permalink
Post by Dimitris Chloupis
disk, 1TB. why it matters ? from my profile its clear that its not the
primitive that is the problem but how Pharo processes pngs.
I happen to work with a lot of big data both in 3d graphics, a blender
file can easily reach 250 mb and it opens under a second and audio files ,
plus instrument that uses alot of audio files as samples of several gbs
giving again instanenous loading. I am not talking here 60 files, I am
talking thousands of files.
I report a sever limitation and I have been told
a) I have not done enough to isolate the problem when I post clear
profiling reports and the code that is responsible for it
The bug report was indeed bad.
Post by Dimitris Chloupis
b) why I make a fuss about it since there are work arounds
I did not see the "why make a fuss about". And the work arounds are
actually helpful, no?
Post by Dimitris Chloupis
c) that its a hardware limitation when the hardware is able to perform
light years ahead of what pharo is currently doing
Sorry but this kind of attitude is really bad, when someone reports a bug
I find it a lot better to tell him that you don't care or not reply at all
and ignore him than just find excuses for the bug or limitation.
You reported a problem with morphics image loading and some people
immediately step in to help you analyse your code. More pepole helped by
giving some tipps and possible workaounds.
What is wrong with this. I don't see a bad attitude.
Post by Dimitris Chloupis
I see it every single time I complain about a problem there is a few
people who are logical about this like Ben , Esteban etc and then some
other that in complete denial zone and easily offended by the truth.
Post by Stephan Eggermont
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading for
them. The total size for all the 60 images is 530kbs . What would happen
if I did some serious animations of 10s of mbs , I will have to go to
buy a coffee to get my GUI opened :D
Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.
Stephan
Dimitris Chloupis
2016-01-16 20:36:43 UTC
Permalink
how the bug report is bad ?

No the workarounds were not helpful because I was already aware of them :)

I appreciate people trying to help as always but yes it was upsetting to me
, to be told that my bug report is bad, that loading 60 tiny images in 1
second is acceptable for a GUI and that opening 60 files is also near the
limitation of my hardware. Because I find every one of them , very far from
the truth and not very helpful.

But I may have overacted also in my part so I apologize. All is good life
goes on :)
Post by Nicolai Hess
Post by Dimitris Chloupis
disk, 1TB. why it matters ? from my profile its clear that its not the
primitive that is the problem but how Pharo processes pngs.
I happen to work with a lot of big data both in 3d graphics, a blender
file can easily reach 250 mb and it opens under a second and audio files ,
plus instrument that uses alot of audio files as samples of several gbs
giving again instanenous loading. I am not talking here 60 files, I am
talking thousands of files.
I report a sever limitation and I have been told
a) I have not done enough to isolate the problem when I post clear
profiling reports and the code that is responsible for it
The bug report was indeed bad.
Post by Dimitris Chloupis
b) why I make a fuss about it since there are work arounds
I did not see the "why make a fuss about". And the work arounds are
actually helpful, no?
Post by Dimitris Chloupis
c) that its a hardware limitation when the hardware is able to perform
light years ahead of what pharo is currently doing
Sorry but this kind of attitude is really bad, when someone reports a bug
I find it a lot better to tell him that you don't care or not reply at all
and ignore him than just find excuses for the bug or limitation.
You reported a problem with morphics image loading and some people
immediately step in to help you analyse your code. More pepole helped by
giving some tipps and possible workaounds.
What is wrong with this. I don't see a bad attitude.
Post by Dimitris Chloupis
I see it every single time I complain about a problem there is a few
people who are logical about this like Ben , Esteban etc and then some
other that in complete denial zone and easily offended by the truth.
Post by Dimitris Chloupis
Post by Dimitris Chloupis
sorry but thats plain horrible performance wise and those images are
needed as soon as the gui is opened. So there can be no lazy loading
for
Post by Dimitris Chloupis
them. The total size for all the 60 images is 530kbs . What would
happen
Post by Dimitris Chloupis
if I did some serious animations of 10s of mbs , I will have to go to
buy a coffee to get my GUI opened :D
Is that on a disk or an SSD? You won't be able to get much more than 60
files opened/s on a disk.
Stephan
Nicolai Hess
2016-01-16 20:51:54 UTC
Permalink
Post by Dimitris Chloupis
how the bug report is bad ?
No the workarounds were not helpful because I was already aware of them :)
I appreciate people trying to help as always but yes it was upsetting to
me , to be told that my bug report is bad, that loading 60 tiny images in 1
second is acceptable for a GUI and that opening 60 files is also near the
limitation of my hardware. Because I find every one of them , very far from
the truth and not very helpful.
But I may have overacted also in my part so I apologize. All is good life
goes on :)
Yes, let's go on.
Stephan Eggermont
2016-01-17 18:55:31 UTC
Permalink
Post by Dimitris Chloupis
I report a sever limitation and I have been told
c) that its a hardware limitation when the hardware is able to perform
light years ahead of what pharo is currently doing
That is because disks can not do much more than that. If you need more
speed you need to make sure the files are not on different tracks, or
cached.

Stephan
Stephan Eggermont
2016-01-17 18:58:06 UTC
Permalink
Post by Dimitris Chloupis
Seems that creating forms and morph from pngs is super slow
Put the forms in one fuel file and materialize that

Stephan
Sven Van Caekenberghe
2016-01-17 19:27:21 UTC
Permalink
Post by Stephan Eggermont
Post by Dimitris Chloupis
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

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
Tudor Girba
2016-01-17 20:17:09 UTC
Permalink
Hi,
Post by Sven Van Caekenberghe
Post by Stephan Eggermont
Post by Dimitris Chloupis
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
Post by Sven Van Caekenberghe
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 Martinez Peck
2016-01-17 21:17:10 UTC
Permalink
Fuel all the way down :)
Post by Dimitris Chloupis
Hi,
Post by Sven Van Caekenberghe
Post by Stephan Eggermont
Post by Dimitris Chloupis
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
Post by Sven Van Caekenberghe
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.
Post by Sven Van Caekenberghe
Sven
--
www.tudorgirba.com
www.feenk.com
"Sometimes the best solution is not the best solution."
--
Mariano
http://marianopeck.wordpress.com
Dimitris Chloupis
2016-01-17 21:25:21 UTC
Permalink
This post might be inappropriate. Click to display it.
Thierry Goubier
2016-01-18 09:27:25 UTC
Permalink
Hi Kilon,
Post by Dimitris Chloupis
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).

Thierry
Post by Dimitris Chloupis
On Sun, Jan 17, 2016 at 11:18 PM Mariano Martinez Peck
Fuel all the way down :)
Hi,
Post by Stephan Eggermont
Post by Dimitris Chloupis
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 inhttps://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 <http://www.tudorgirba.com>
www.feenk.com <http://www.feenk.com>
"Sometimes the best solution is not the best solution."
--
Mariano
http://marianopeck.wordpress.com
Stephan Eggermont
2016-01-18 10:11:04 UTC
Permalink
Post by Esteban Lorenzano
Hi Kilon,
Post by Dimitris Chloupis
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
Dimitris Chloupis
2016-01-18 10:46:25 UTC
Permalink
I am not convinced, the problem is that 80% of my slow down is on the pharo
side , the primitive takes 200ms to read the file, 900-1000 ms are taken to
convert to Form so I dont see how making sprites will help me much. I know
you want to blame the hardware , but this is clearly a pharo issue. I have
already posted the my profiling results.

Since half of form creation is the seconds indicator I can stream it so it
loads one png per second which should make the opening of gui much faster.
I will find a way , its not a big deal.

This thread was never about a problem I cant solve , but rather a notice
that there is a part of pharo that is highly inefficient.
Post by Stephan Eggermont
Post by Esteban Lorenzano
Hi Kilon,
Post by Dimitris Chloupis
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
stepharo
2016-01-18 18:22:47 UTC
Permalink
Pay attention the JPEG reader is getting old and does not support latest
version.

Stef
Post by Tudor Girba
Hi,
Post by Sven Van Caekenberghe
Post by Stephan Eggermont
Post by Dimitris Chloupis
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
Post by Sven Van Caekenberghe
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."
Hilaire
2016-01-18 14:27:19 UTC
Permalink
Fuel is very easy to use and pretty fast. Sadly from one image to
another you have to migrate your fuel data.

An alternative will be to use an Sqlite database, it comes with a bonus:
the format is stable. No idea about speed however.

Hilaire
Post by Stephan Eggermont
Put the forms in one fuel file and materialize that
--
Dr. Geo
http://drgeo.eu
Esteban A. Maringolo
2016-01-18 14:55:06 UTC
Permalink
If you use that many images and require all of them at once, maybe
spriting them is an option. That's the first recommendation using a
gaming-based approach.

Regards,
Esteban A. Maringolo
Post by Hilaire
Fuel is very easy to use and pretty fast. Sadly from one image to
another you have to migrate your fuel data.
the format is stable. No idea about speed however.
Hilaire
Post by Stephan Eggermont
Put the forms in one fuel file and materialize that
--
Dr. Geo
http://drgeo.eu
Hilaire
2016-01-19 09:31:08 UTC
Permalink
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
Denis Kudriashov
2016-01-19 10:22:33 UTC
Permalink
Interesting what is faster: reading Form from fuel file or reading it from
simple BMP file?
Post by Hilaire
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
Dimitris Chloupis
2016-01-19 10:34:06 UTC
Permalink
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.
Post by Denis Kudriashov
Interesting what is faster: reading Form from fuel file or reading it from
simple BMP file?
Post by Hilaire
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
Denis Kudriashov
2016-01-19 10:59:26 UTC
Permalink
Post by Dimitris Chloupis
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))"
PBKResearch
2016-01-19 11:29:35 UTC
Permalink
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.



Peter Kenny



From: Pharo-users [mailto:pharo-users-***@lists.pharo.org] On Behalf Of Denis Kudriashov
Sent: 19 January 2016 10:59
To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
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 <***@gmail.com <mailto:***@gmail.com> >:

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))"
Sven Van Caekenberghe
2016-01-19 11:34:22 UTC
Permalink
Post by PBKResearch
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.
Post by PBKResearch
Peter Kenny
Sent: 19 January 2016 10:59
Subject: Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5
Post by Dimitris Chloupis
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.
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))"
Esteban Lorenzano
2016-01-19 12:21:20 UTC
Permalink
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
Post by Sven Van Caekenberghe
Post by PBKResearch
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.
Post by PBKResearch
Peter Kenny
Sent: 19 January 2016 10:59
Subject: Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5
Post by Dimitris Chloupis
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.
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))"
Denis Kudriashov
2016-01-19 12:39:48 UTC
Permalink
And more extended test:

Smalltalk garbageCollect; garbageCollect.
r1:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s |
s binary.
fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] benchFor:
2 seconds.

Smalltalk garbageCollect; garbageCollect.
r2 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s |
s binary.
fromBMP := BMPReadWriter new on: s; nextImage]] benchFor: 2 seconds.

Smalltalk garbageCollect; garbageCollect.
r3 := [FileLocator imageDirectory / 'test.png' readStreamDo: [ :s |
s binary.
fromPNG := PNGReadWriter new on: s; nextImage]] benchFor: 2 seconds.

Smalltalk garbageCollect; garbageCollect.
r4:= [
fromAthens := (AthensCairoSurface
createFromFile: (FileLocator imageDirectory / 'test.png') pathString
ifFailed: []) asForm.
] benchFor: 2 seconds.


{ r1. r2. r3. r4 }.
"an Array(a BenchmarkResult(5,537 iterations in 2 seconds 2 milliseconds.
2,766 per second) a BenchmarkResult(2,193 iterations in 2 seconds 2
milliseconds. 1,095 per second) a BenchmarkResult(443 iterations in 2
seconds 5 milliseconds. 220.948 per second) a BenchmarkResult(1,033
iterations in 2 seconds 3 milliseconds. 515.726 per second))"
Post by Esteban Lorenzano
[(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
Post by Sven Van Caekenberghe
Post by PBKResearch
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.
Post by Sven Van Caekenberghe
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
Peter Kenny
Behalf Of Denis Kudriashov
Post by Sven Van Caekenberghe
Post by PBKResearch
Sent: 19 January 2016 10:59
Subject: Re: [Pharo-users] Creation form from PNG file very slow on
Pharo 4 and 5
Post by Sven Van Caekenberghe
Post by PBKResearch
Post by Dimitris Chloupis
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
You are right. I perform little experiment. Fuel reading is 60% faster
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
{ 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))"
Dimitris Chloupis
2016-01-19 12:52:41 UTC
Permalink
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.
Post by Esteban Lorenzano
[(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
Post by Sven Van Caekenberghe
Post by PBKResearch
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.
Post by Sven Van Caekenberghe
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
Peter Kenny
Behalf Of Denis Kudriashov
Post by Sven Van Caekenberghe
Post by PBKResearch
Sent: 19 January 2016 10:59
Subject: Re: [Pharo-users] Creation form from PNG file very slow on
Pharo 4 and 5
Post by Sven Van Caekenberghe
Post by PBKResearch
Post by Dimitris Chloupis
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
You are right. I perform little experiment. Fuel reading is 60% faster
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
{ 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))"
Dimitris Chloupis
2016-01-19 13:02:58 UTC
Permalink
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.
Post by Dimitris Chloupis
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.
Post by Esteban Lorenzano
[(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
Post by Sven Van Caekenberghe
Post by PBKResearch
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.
Post by Sven Van Caekenberghe
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
Peter Kenny
Behalf Of Denis Kudriashov
Post by Sven Van Caekenberghe
Post by PBKResearch
Sent: 19 January 2016 10:59
Subject: Re: [Pharo-users] Creation form from PNG file very slow on
Pharo 4 and 5
Post by Sven Van Caekenberghe
Post by PBKResearch
Post by Dimitris Chloupis
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
You are right. I perform little experiment. Fuel reading is 60% faster
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.
Post by Sven Van Caekenberghe
Post by PBKResearch
{ 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))"
Ben Coman
2016-01-19 13:29:22 UTC
Permalink
$ 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
Post by Dimitris Chloupis
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.
Post by Dimitris Chloupis
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.
Post by Esteban Lorenzano
[(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
Post by Sven Van Caekenberghe
Post by PBKResearch
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.
Post by PBKResearch
Peter Kenny
Behalf Of Denis Kudriashov
Sent: 19 January 2016 10:59
Subject: Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5
Post by Dimitris Chloupis
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.
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))"
Dimitris Chloupis
2016-01-19 13:44:08 UTC
Permalink
thanks ben that indeed get the cairo 32 bit version but there must be a
version mismatch because now pharo complains
"Error:Could not find accessor for variable named "aCairoSurfaceHandle" "
Post by Ben Coman
$ 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
Post by Dimitris Chloupis
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.
Post by Dimitris Chloupis
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.
Post by Esteban Lorenzano
[(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
Post by Sven Van Caekenberghe
Post by PBKResearch
Denis
Very interesting. It would be more interesting if you could save
your
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
Post by PBKResearch
test image as a .png file, and then include reading with
PNGReadWriter in
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
Post by PBKResearch
your comparison. This would help to confirm or refute the original
point
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
Post by PBKResearch
made by Dimitris, that reading from .png is particularly slow.
Check the original thread/case, it is slow. Not *very* slow, but
slower
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
than the plugin based JPEG reader. That is what we eventually need,
a plugin
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
base PNG reader.
Post by PBKResearch
Peter Kenny
Behalf Of Denis Kudriashov
Sent: 19 January 2016 10:59
To: Any question about pharo is welcome <
Subject: Re: [Pharo-users] Creation form from PNG file very slow on
Pharo 4 and 5
Post by Dimitris Chloupis
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
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
Post by PBKResearch
Post by Dimitris Chloupis
any format I use. Or else I end up worrying about things I should
not be
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
Post by PBKResearch
Post by Dimitris Chloupis
worrying about.
You are right. I perform little experiment. Fuel reading is 60%
faster
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
Post by PBKResearch
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
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
Post by PBKResearch
milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations
in 2
Post by Dimitris Chloupis
Post by Dimitris Chloupis
Post by Esteban Lorenzano
Post by Sven Van Caekenberghe
Post by PBKResearch
seconds 3 milliseconds. 2,860 per second))"
Continue reading on narkive:
Loading...