Creation form from PNG file very slow on Pharo 4 and 5
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-slo...
2016-01-16 13:50 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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-slo...
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"
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 On Sat, Jan 16, 2016 at 3:41 PM Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 13:50 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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-slo...
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"
On 16-01-16 14:48, Dimitris Chloupis wrote:
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
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. On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <stephan@stack.nl> wrote:
On 16-01-16 14:48, Dimitris Chloupis wrote:
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
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. On Sat, Jan 16, 2016 at 4:40 PM Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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.
On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <stephan@stack.nl> wrote:
On 16-01-16 14:48, Dimitris Chloupis wrote:
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
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
On 16 Jan 2016, at 15:47, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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.
On Sat, Jan 16, 2016 at 4:40 PM Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: 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.
On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>> wrote: On 16-01-16 14:48, Dimitris Chloupis wrote:
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
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 :) On Sat, Jan 16, 2016 at 5:49 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
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
On 16 Jan 2016, at 15:47, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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.
On Sat, Jan 16, 2016 at 4:40 PM Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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.
On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <stephan@stack.nl> wrote:
On 16-01-16 14:48, Dimitris Chloupis wrote:
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
On 16 Jan 2016, at 17:17, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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
On Sat, Jan 16, 2016 at 5:49 PM Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: 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
On 16 Jan 2016, at 15:47, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
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.
On Sat, Jan 16, 2016 at 4:40 PM Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: 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.
On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>> wrote: On 16-01-16 14:48, Dimitris Chloupis wrote:
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
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 :) On Sat, Jan 16, 2016 at 6:24 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Jan 2016, at 17:17, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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
On Sat, Jan 16, 2016 at 5:49 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
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
On 16 Jan 2016, at 15:47, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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.
On Sat, Jan 16, 2016 at 4:40 PM Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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.
On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <stephan@stack.nl> wrote:
On 16-01-16 14:48, Dimitris Chloupis wrote:
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
2016-01-16 15:40 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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.
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?
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.
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.
On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <stephan@stack.nl> wrote:
On 16-01-16 14:48, Dimitris Chloupis wrote:
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
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 :) On Sat, Jan 16, 2016 at 9:51 PM Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 15:40 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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.
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?
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.
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.
On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <stephan@stack.nl> wrote:
On 16-01-16 14:48, Dimitris Chloupis wrote:
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
2016-01-16 21:36 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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.
On 16-01-16 15:40, Dimitris Chloupis wrote:
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
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" < kilon.alios@gmail.com> напиÑал:
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
On Sat, Jan 16, 2016 at 3:41 PM Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 13:50 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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-slo...
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"
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. On Sat, Jan 16, 2016 at 4:07 PM Denis Kudriashov <dionisiydk@gmail.com> wrote:
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" < kilon.alios@gmail.com> напиÑал:
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
On Sat, Jan 16, 2016 at 3:41 PM Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-16 13:50 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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-slo...
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"
2016-01-16 15:30 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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.
On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan@stack.nl> 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-slo... 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
Hi,
On Jan 17, 2016, at 8:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan@stack.nl> 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-slo...
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."
Fuel all the way down :) On Sun, Jan 17, 2016 at 5:17 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jan 17, 2016, at 8:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan@stack.nl> 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-slo...
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
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 On Sun, Jan 17, 2016 at 11:18 PM Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Fuel all the way down :)
On Sun, Jan 17, 2016 at 5:17 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jan 17, 2016, at 8:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan@stack.nl> 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-slo...
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
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). Thierry
On Sun, Jan 17, 2016 at 11:18 PM Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote:
Fuel all the way down :)
On Sun, Jan 17, 2016 at 5:17 PM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
> On Jan 17, 2016, at 8:27 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote: > > >> On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>> 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 inhttps://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-slo...
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
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
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. On Mon, Jan 18, 2016 at 12:12 PM Stephan Eggermont <stephan@stack.nl> wrote:
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
Pay attention the JPEG reader is getting old and does not support latest version. Stef Le 17/1/16 21:17, Tudor Girba a écrit :
Hi,
On Jan 17, 2016, at 8:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan@stack.nl> 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-slo... 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."
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 Le 17/01/2016 19:58, Stephan Eggermont a écrit :
Put the forms in one fuel file and materialize that
-- Dr. Geo http://drgeo.eu
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 2016-01-18 11:27 GMT-03:00 Hilaire <hilaire@drgeo.eu>:
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
Le 17/01/2016 19:58, Stephan Eggermont a écrit :
Put the forms in one fuel file and materialize that
-- Dr. Geo http://drgeo.eu
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
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 <hilaire@drgeo.eu>:
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
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. On Tue, Jan 19, 2016 at 12:23 PM Denis Kudriashov <dionisiydk@gmail.com> wrote:
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 <hilaire@drgeo.eu>:
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
2016-01-19 11:34 GMT+01:00 Dimitris Chloupis <kilon.alios@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))"
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-bounces@lists.pharo.org] On Behalf Of Denis Kudriashov Sent: 19 January 2016 10:59 To: Any question about pharo is welcome <pharo-users@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 <kilon.alios@gmail.com <mailto:kilon.alios@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))"
On 19 Jan 2016, at 12:29, PBKResearch <peter@pbkresearch.co.uk> 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:pharo-users-bounces@lists.pharo.org] On Behalf Of Denis Kudriashov Sent: 19 January 2016 10:59 To: Any question about pharo is welcome <pharo-users@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 <kilon.alios@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))"
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 <sven@stfx.eu> wrote:
On 19 Jan 2016, at 12:29, PBKResearch <peter@pbkresearch.co.uk> 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:pharo-users-bounces@lists.pharo.org] On Behalf Of Denis Kudriashov Sent: 19 January 2016 10:59 To: Any question about pharo is welcome <pharo-users@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 <kilon.alios@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))"
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))" 2016-01-19 13:21 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
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 <sven@stfx.eu> wrote:
On 19 Jan 2016, at 12:29, PBKResearch <peter@pbkresearch.co.uk> 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:pharo-users-bounces@lists.pharo.org] On Behalf Of Denis Kudriashov Sent: 19 January 2016 10:59 To: Any question about pharo is welcome <pharo-users@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 <kilon.alios@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))"
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 <estebanlm@gmail.com> 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 <sven@stfx.eu> wrote:
On 19 Jan 2016, at 12:29, PBKResearch <peter@pbkresearch.co.uk> 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:pharo-users-bounces@lists.pharo.org] On Behalf Of Denis Kudriashov Sent: 19 January 2016 10:59 To: Any question about pharo is welcome <pharo-users@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 <kilon.alios@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))"
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 <kilon.alios@gmail.com> 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 <estebanlm@gmail.com> 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 <sven@stfx.eu> wrote:
On 19 Jan 2016, at 12:29, PBKResearch <peter@pbkresearch.co.uk> 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:pharo-users-bounces@lists.pharo.org] On Behalf Of Denis Kudriashov Sent: 19 January 2016 10:59 To: Any question about pharo is welcome <pharo-users@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 <kilon.alios@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))"
$ 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 <kilon.alios@gmail.com> 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 <kilon.alios@gmail.com> 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 <estebanlm@gmail.com> 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 <sven@stfx.eu> wrote:
On 19 Jan 2016, at 12:29, PBKResearch <peter@pbkresearch.co.uk> 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:pharo-users-bounces@lists.pharo.org] On Behalf Of Denis Kudriashov Sent: 19 January 2016 10:59 To: Any question about pharo is welcome <pharo-users@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 <kilon.alios@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))"
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" " On Tue, Jan 19, 2016 at 3:30 PM Ben Coman <btc@openinworld.com> wrote:
$ 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 <kilon.alios@gmail.com> 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 <kilon.alios@gmail.com
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 <estebanlm@gmail.com> 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 <sven@stfx.eu>
wrote:
On 19 Jan 2016, at 12:29, PBKResearch <peter@pbkresearch.co.uk>
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:pharo-users-bounces@lists.pharo.org] On Behalf Of Denis Kudriashov Sent: 19 January 2016 10:59 To: Any question about pharo is welcome < pharo-users@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 <kilon.alios@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))"
participants (14)
-
Ben Coman -
Denis Kudriashov -
Dimitris Chloupis -
Esteban A. Maringolo -
Esteban Lorenzano -
Hilaire -
Mariano Martinez Peck -
Nicolai Hess -
PBKResearch -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba