Am 23.05.2013 um 10:19 schrieb Sven Van Caekenberghe <[email protected]>:
> > 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 ! > Yep and it works good. Although being a little bit stupid one of my favorite tests is still testNoDebuggers self assert: (SystemWindow allSubInstances select: [:each| each model isKindOf: Debugger ]) size = 0 So whenever a debugger window opens, monit sends an email telling me :) > So cool that I want to make that into a general purpose Zn handler (totally > optional and on localhost only of course) ;-) > Yes, that is a good idea. You just need to overwrite some things in Zinc and package your stuff in an extra package so I can unload it :P Norbert >> 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 >>> >>> >>> >>> >>> >> >> > >
