2008/10/27 Stuart McCulloch <[EMAIL PROTECTED]>
> 2008/10/27 Gili <[EMAIL PROTECTED]>
>
>>
>> Just as a side-note, why has Guice 2.0 gotten so fat? Guice 1.0 was
>> 540k. Guice 2.0 is 950k. Seems a bit excessive for a DI framework. If
>> Guice was my only dependency I wouldn't worry so much but this is part
>> of a growing pattern, the total of all my dependencies has grown into
>> the multi-megabytes. This makes life difficult for desktop
>> applications...
>>
>
> most of the extra bytes has come from pulling in google collections,
> if I change build.xml to remove this then guice core is around 486k
>
> I don't know if this is because guice uses most of the collections lib,
> or perhaps jarjar isn't able to remove the unused classes because of
> inter-dependencies, but it does end up embedding most classes...
>
> ps. if I remove cglib from build.xml it drops down to ~359k, which
> means we're only using 127k from the cglib library (overall 272k)
> and with no embedded dependencies guice core is only 314k
>
> so, in summary:
>
here are better numbers (previously I used Java6 bytecode, but there's a
known jarjar issue with Java6 bytecode where it misses certain classes)
309k core
44k asm
160k cglib
439k collections
====
952k guice
still it shows that most of the footprint increase has come from collections
(of course the collections classes are invaluable and don't come for free!)
This discussion is somewhat related to unbundling CGLIB from Guice
>> because my project already has it as an external dependency.
>
>
> well, the figures show removing CGLIB wouldn't make much difference
> because guice uses less than half of the jar - in fact removing it would
> actually increase the footprint for people who don't use it elsewhere,
> as they'd have to load the whole CGLIB jar.
>
> the major win would be if we could trim down the collections classes
>
> And surprisingly, CGLIB is itself a fat library compared to ASM... ASM
>> does a lot of difficult work compared to CGLIB which makes you wonder
>> why the latter is 3x larger!
>>
>
> actually providing a proxy framework is not as easy as you might think,
> especially wrt. analyzing classes, etc. - and while ASM does reduce the
> workload, you still need a lot of calls to ASM to generate classes, etc.
>
> so I'm not that surprised it's larger (and if you see anything in CGLIB
> that could be trimmed down, then I'm sure they'd be happy to fix it)
>
> Gili
>>
> --
> Cheers, Stuart
>
--
Cheers, Stuart
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
