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.
