Hmm, there are different views possible on this. We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable. I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO. On 23 May 2013, at 09:43, Camillo Bruni <camillobr...@gmail.com> wrote: > On 2013-05-23, at 09:35, Norbert Hartl <norb...@hartl.name> wrote: > >> Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobr...@gmail.com>: >> >>>>>> >>>>> technically yes, but you do not need many things to run the code: >>>>> - class comments >>>>> - method comments >>>>> - any documentation in general >>>>> >>>> >>>> And I don't have it at production because I don't have changes file here. >>>> >>>> >>>>> yet you load them. so I wonder if it makes sense to even load tests >>>>> separately? >>>>> >>>> >>>> It make sense when you try to reduce production image size. And loading >>>> only required packages (without tests) works well. Why change it? >>> >>> I know that this scheme is in use, but why? why do I have to reduce the size >>> of a production image? from how many to many megabytes? It might make sense >>> for moose, but none of the other projects. Do you really care if the image >>> is >>> 35 instead of 25MB? To me this argument sounds invalid :/ >>> >> I can tell from a server deployment perspective. A production image should >> only contain the source it really needs. Additional not-used code cannot >> have a benefit but it could cause side effects (breaking things, slowing >> things down, opening security holes, etc…). So you reduce it to the bare >> essentials. Having less code also makes an image faster which is not a >> noticable effect but it is there. Finally if you want to have 48 images >> (that can be feasible on a 16 core machine) on your machine then it would >> sum up to 480 MB which is less memory for additional images or OS I/O cache >> which in turn makes your machine slower. >> Not carrying about memory at all is a typical view point that the java >> community developed. But your professional acting should be reasonable. That >> means for every action should have a reason. At best a good reason. Growing >> the image by supporting new possibilties and tools is a good reason. Just >> wasting memory because it is easier to load a huge bunch is IMHO not a good >> reason. > > So I conclude that for a production ready image you want to strip out as much > as possible: > - tests > - comments (luckily in the changes file...) > - source code (luckily in the changes file...) > - monticello metadata (which was around 5MB or so, did anybody care?) > - font files that linger around (also around 2MB, and also mostly ignored) > > which sort of makes sense, however for that you will need a custom tool, > which is orthogonal > to being able to load tests in a separate package. And the test only > contribute to the static > code base, whereas in a live production environment I would expect to have > more live objects > (I am guessing here)?. > > So for a production environment, if you want to get these small MB savings on > the image you > need a decent script. I would really like to have real numbers on how much > the tests contribute > to the total size. -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
