Steve Clark <[EMAIL PROTECTED]> wrote:
>A) code size
>Clearly, clients that are not interested in supporting Bi-Di should not
>have to pay a significant penalty for the additional code required for
>Bi-Di. The two ways we can think to minimize the impact are to factor
>as much as possible into a separate library, or to leave significant
>code chunks in #ifdef BIDI blocks. I'd like to urge people to think
>about which code could reasonably be factored into it's own library,
>since the support costs for #ifdef code is high.
See my reply to Erik for some statistics.
The most obvious candidate for a separate library is the Bidi
utilities in intl\unicharutil. Currently these more than double the
size of ucharuti.dll. If we move these into their own directory (say
intl\bidiutil), that would probably also be a good place to put
libraries for the remaining platform-specific code. I understand we
need permission from the module owner to do this -- this is one of the
things we should talk about on Thursday.
Other than that, the greatest increase is of course in layout:
gkhtml.dll grows by ~190K, over 10%. Here it would be much more
difficult to factor out the Bidi code, since it is mostly made up of
small changes scattered very widely through the tree.
Simon
