Am 23.05.2013 um 09:43 schrieb Camillo Bruni <[email protected]>:
> > 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: If we assume that we have a use case where it is a requirement, yes! I didn't want to tell it is needed for every deployment. > - tests yes, because tests are not used and tests are code that depends on other modules. > - comments (luckily in the changes file…) I didn't know comments can be in-image. But if so I would say: If this can be done in a feasible way and saving memory is king then yes I would do it. > - source code (luckily in the changes file…) same as for comments > - monticello metadata (which was around 5MB or so, did anybody care?) This one thing that is done by "cleanUpForProduction". Btw. cleanUpForProduction is exactly what I mean, a workflow to clean unnecessary stuff. > - font files that linger around (also around 2MB, and also mostly ignored) > Yes, I think cleanUpForProduction does this as well. Being able to disable freetype, unload the freetype stuff and have a small bitmap font that can be used as a replacement is good. > 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)?. > The tool is cleanUpForProduction. I don't know how you define orthogonality and so I don't get the second sentence. What is a static code base in smalltalk? .sources/.changes? Aren't there classes, class initializations, etc. whenever you load additional code? Maybe you can elaborate on that point. > 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. If you want to save size it doesn't matter how much it is as long as there is an easy way to save it. But this is not only about size. Code that gets loaded might do things in class initialization that opens a security hole or it might that just the presence of the code makes it more vulnerable. I don't like to discuss security issues here. My statement is that in production every single piece that is not used doesn't bring any benefit but it can waste memory, cpu cycles and open security holes. So what reasons can be there to load that stuff if you easily can avoid it? Norbert
