minutes of ESC call ...
sbergman at redhat.com
Fri Nov 14 01:26:29 PST 2014
On 11/14/2014 07:49 AM, Noel Grandin wrote:
> On 2014-11-13 06:13 PM, Michael Meeks wrote:
>> * library bloat (Michael S)
>> + not really an issue for release builds - --enable-mergelibs
>> + big library + --enable-symbols -> OOM
>> + especially problematic CppuniTests with use_library_objects
>> + perhaps a barrier to entry to new developers
>> + Calc: (with debuginfo) 4.1 - 413Mb, 4.3 - 512Mb, master - 600Mb
>> (stripped) 4.3 - 26.8Mb master - 30Mb
>> + linking in parallel gives OOM issues.
>> => avoid making libraries even bigger.
>> + new calc engine uses lots of templates (Markus)
>> + mdds usage is restricted to only a few modules: (Kohei)
>> + 5-6 translation units only.
>> + whole code-base is using lots more templates (Markus)
>> + compilation speed also got more than 2x slower (Kohei)
>> + use of own templates & container -> STL
>> + recently turned a lot of methods to inline methods
>> left/right (Kohei)
> Some suggestions:
> (1) Would it make a difference if I went through the *.hxx files,
> marking the inline methods with an explicit inline qualifier?
Yes, it would needlessly clutter the code. ;) I don't see what benefit
you're trying to achieve here?
> (2) Perhaps we need to be using the extern template feature to limit the
> number of instantiations of various templates?
Template instantiations, via the typical "all-inline" nature of the
template declarations, have hidden visibility and should end up with one
copy per dynamic object. I'm not sure whether there would be much
compile- or run-time benefit from using another strategy (plus, I'm not
sure whether it would work well across the various toolchains to give
template instantiations non-hidden visibility).
More information about the LibreOffice