Librairy size in OCL

I'm only posting to dev because I don't think it is usefull to everybody.

Is it normal that these 2 libraries are so big :
librtt-typekit-gnulinux.so.2.2.0 = 28M
librtt-scripting-gnulinux.so.2.2.0 = 41M

Librairy size in OCL

On Friday 17 December 2010 00:40:04 Willy Lambert wrote:
> I'm only posting to dev because I don't think it is usefull to everybody.
>
> Is it normal that these 2 libraries are so big :
> librtt-typekit-gnulinux.so.2.2.0 = 28M
> librtt-scripting-gnulinux.so.2.2.0 = 41M

Yes. But we don't consider it as a 'feature'. The idea is that most template-
generated code ends up in typekits and that the user app/components link to
these such that only the typekit is somewhat big, but the components are
small.

The code size of these libraries is about 1/3 of the filesize, which is still
quite some.

I hope to get some better figures in 2.3.0, but don't expect that a typekit of
16 types will be 1M lib. We currently have 560k code per type. Don't expect we
can cut that in half.

Peter

Librairy size in OCL

Personally, I don't expect anything, memory is not a problem :) I was just
surprised and at the end of course it's better to have one big lib instead
of big user libs

2010/12/20 Peter Soetens <peter [..] ...>

> On Friday 17 December 2010 00:40:04 Willy Lambert wrote:
> > I'm only posting to dev because I don't think it is usefull to everybody.
> >
> > Is it normal that these 2 libraries are so big :
> > librtt-typekit-gnulinux.so.2.2.0 = 28M
> > librtt-scripting-gnulinux.so.2.2.0 = 41M
>
> Yes. But we don't consider it as a 'feature'. The idea is that most
> template-
> generated code ends up in typekits and that the user app/components link to
> these such that only the typekit is somewhat big, but the components are
> small.
>
> The code size of these libraries is about 1/3 of the filesize, which is
> still
> quite some.
>
> I hope to get some better figures in 2.3.0, but don't expect that a typekit
> of
> 16 types will be 1M lib. We currently have 560k code per type. Don't expect
> we
> can cut that in half.
>
> Peter
>