Nice improvement with the noinline directive. If this is the total over 100
separately compiled modules, then I'm not especially worried about the
remaining 200k or so that could theoretically be reclaimed.
This is killing me, I really want to use it as a replacement for
Strutil::format and ustring::format. But the compiler issue stands in the way
-- we just can't count on everybody who needs OIIO having a modern enough
compiler for variadic templates. (Right?) And having to #ifdef it and worry
about the C++98 implementation seems like enough of a pain to make it not worth
the exercise.
-- lg
On Jul 28, 2011, at 9:50 AM, Chris Foster wrote:
> On Fri, Jul 29, 2011 at 12:44 AM, Chris Foster <[email protected]> wrote:
>> Correction: It appears I was quite wrong about this for the current source.
>> The above results are without optimizations turned on, which of course will
>> change the bloat calculation a lot due to inlining, which is the whole point
>> (duh!) Running the tinyformat test again with -O3 gives a massive 1.6Mb
>> executable, ouch!
>
> With a careful placement of a single __attribute__((noinline)) and removing
> some other unnecessary inlines, here's an updated table for a -O3 build
>
> ====================== ================== ==========================
> test name total compile time executable size (stripped)
> ====================== ================== ==========================
> printf 1.6s 44K (32K)
> std::ostream 9.5s 80K (60K)
> tinyformat 33.6s 340K (308K)
> tinyformat, c++0x mode 36.2s 340K (308K)
> tinyformat, no inlines 21.0s 168K (144K)
> boost::format 101.1s 1.2M (1.1M)
> ====================== ================== ==========================
>
> We can further reduce the "tinyformat, no inlines" case to 88K by spamming
> noinlines everywhere on the template definitions, but I'm not sure it's
> worthwhile. The main question then is whether it's worth complicating the
> library implementation to allow for optional separate compilation which will
> give us that factor of two between 308K and 144K. I implemented it, but it's
> a
> little messy. Opinions?
>
> ~Chris.
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
