CPU and RAM usage of Pharo3 vs. Pharo6
Hey! my current major deployment is still with Pharo3 and due some bigger changes I start to migrate to Pharo6 and today I finally managed to update the test deployment (and be happy with it). The test is not scientific but maybe an early indicator that there is something to look at? The image is idle and not handling any application payload so it might be a fair comparison because of that. RSS + ~16 MiB RAM (~53 Mib vs. ~69 Mib) CPU + ~0.005s per real second passed (think of Amazon AWS why that could matter) (In ~1400s wall clock 57.8s vs. 50.86s cpu time was used) Does anyone else see this increased usage? Has anyone explored the source of it? Does anyone of you share the concern I have? :) holger Outline of the setup: * Take a Pharo3 or Pharo6 base image * Load my code (and its dependencies, big difference is version of Voyage) * Start the images on the test system * Opens a TCP connection, initialize VoyageMongo * Wait for work Look at top for RSS and CPU time used.
There is a server mode option somewhere that could reduce some usage. Maybe it will help. Phil Le 9 juin 2017 13:07, "Holger Freyther" <holger@freyther.de> a écrit :
Hey!
my current major deployment is still with Pharo3 and due some bigger changes I start to migrate to Pharo6 and today I finally managed to update the test deployment (and be happy with it). The test is not scientific but maybe an early indicator that there is something to look at?
The image is idle and not handling any application payload so it might be a fair comparison because of that.
RSS + ~16 MiB RAM (~53 Mib vs. ~69 Mib) CPU + ~0.005s per real second passed (think of Amazon AWS why that could matter) (In ~1400s wall clock 57.8s vs. 50.86s cpu time was used)
Does anyone else see this increased usage? Has anyone explored the source of it? Does anyone of you share the concern I have? :)
holger
Outline of the setup:
* Take a Pharo3 or Pharo6 base image * Load my code (and its dependencies, big difference is version of Voyage) * Start the images on the test system * Opens a TCP connection, initialize VoyageMongo * Wait for work
Look at top for RSS and CPU time used.
On 9. Jun 2017, at 19:11, philippe.back@highoctane.be <philippe.back@gmail.com> wrote:
Hi!
There is a server mode option somewhere that could reduce some usage.
related to Morphic polling? Right now the images still install RFB to help poking it at runtime (I should use the remote debugging for sure) so disabling morphic completely might not be an option yet? holger
On 9. Jun 2017, at 23:09, Holger Freyther <holger@freyther.de> wrote:
related to Morphic polling? Right now the images still install RFB to help poking it at runtime (I should use the remote debugging for sure) so disabling morphic completely might not be an option yet?
WorldState serverMode: true? And while looking at the usage it reminds me of some changes we should do for Pharo7. :) holger
On 9 Jun 2017, at 13:06, Holger Freyther <holger@freyther.de> wrote:
Hey!
my current major deployment is still with Pharo3 and due some bigger changes I start to migrate to Pharo6 and today I finally managed to update the test deployment (and be happy with it). The test is not scientific but maybe an early indicator that there is something to look at?
The image is idle and not handling any application payload so it might be a fair comparison because of that.
RSS + ~16 MiB RAM (~53 Mib vs. ~69 Mib)
I think this is just size of image increase (e.g. new tools, tutorials, demos...). We need to clean the image in Pharo7⦠e.g. remove all the old versions of things that we have now a new version of. For Pharo 6: you can unload some things (e.g. Help packages, maybe tests) to shrink (see ImageCleaner). For Pharo7 with the bootstrap we are already better: Image size is 30MB instead of 36, and I think people will use the bootstrap to build images specialised much more (e.g without UI, but remote tools).
CPU + ~0.005s per real second passed (think of Amazon AWS why that could matter) (In ~1400s wall clock 57.8s vs. 50.86s cpu time was used)
That is not good⦠I think there where some changes regarding the main rendering loop. It might be interesting to track them down (since Phaor3 that is a lot of potential changes, though). Or better, think about a better headless way of running servers (no UI, use Remote tools instead). Marcus
participants (3)
-
Holger Freyther -
Marcus Denker -
philippe.back＠highoctane.be