On 23 May 2013, at 10:12, Norbert Hartl <[email protected]> wrote: > Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <[email protected]>: > >> Hmm, there are different views possible on this. >> > Absolutely! > >> 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. >> > That's my only point. Having tests packaged separately just opens the > possibility to make things smaller. > >> 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. >> > agreed. > >> 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. >> > That is the funny part in this discussion. I stopped minimizing them as well. > On most images I use RFB and like to have the full fledge installation being > present. I stopped even to use cleanUpForProduction because it removes SUnit. > I hook up SUnit to rest handlers and trigger them from the outside to do > runtime sanity checks, e.g. used by monit.
That is a cool trick ! So cool that I want to make that into a general purpose Zn handler (totally optional and on localhost only of course) ;-) > Norbert >> On 23 May 2013, at 09:43, Camillo Bruni <[email protected]> wrote: >> >>> On 2013-05-23, at 09:35, Norbert Hartl <[email protected]> wrote: >>> >>>> Am 23.05.2013 um 09:18 schrieb Camillo Bruni <[email protected]>: >>>> >>>>>>>> >>>>>>> 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 >> >> >> >> >> > >
