El sáb, 07-11-2009 a las 19:33 +0100, Adrian Lienhard escribió:
Yes, in "normal" use of Pharo, holding the sources in memory would only consume a fraction of the available RAM. Some applications, however, have several hundred images running at the same time on a server. In this case the picture looks very different again.
I think that the pros of not having a separate sources files surpases the cons of having a couple more MB per image. Also, in deployment, a core image will be used that it is very striped already so the sources are even smaller and the overhead in the image is better. I vote for +1 on having sources inside the image as other resources (bitmaps, fonts, etc). And, if the sources can be stripped also from the image for deployment, the additional MB aren't an issue either.
I think Marcus' idea of swapping in/out ressources is very interesting. We could get rid of the ancient sources handling but still have a low, or even lower, memory footprint.
Cheers, Adrian
On Nov 7, 2009, at 19:21 , Marcus Denker wrote:
On Nov 7, 2009, at 7:13 PM, Nicolas Cellier wrote:
Perhaps it's time to finally get rid of source pointers and just keep the source code as objects in the image, referenced directly from the CompiledMethod.
External sources were necessary 25 years ago when an image without sources consumed 3/4 of the total RAM of the machine, but it's not like that anymore.
+100
I did that once as an experiment: searching for strings in all the code gets *fast*.
I'd say +16M
This is what i got when condensing sources: 16249263 2009-10-19 20:25 PharoV10.sources
yes, but nevertheless, this is how much percent of the Ram of your machine?
Two notes:
- We could compress the source-strings. That should lead to something like 5MB increase.
- We should invest into a general mechanism of swapping in unused objects on demand. It's fun that there is a special case for the source, but all the other resources happily live in the image (bitmaps, sounds... in general objects not part of the working set, e.g. I guess 80% of all compiled methods...).
Marcus
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx