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. 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 > > > > >
