Re: [lmi] reusing mc_enum<> for serialization into XML

[Greg Chicares]

On 2010-02-02 08:07Z, Vaclav Slavik wrote:
> 
> [...] Raw patch is here:
> http://review.bakefile.org/r/154/diff/raw/

Thanks. I'm still working on a final version to commit. Meanwhile...

> On Sun, 2010-01-17 at 17:08 +0000, Greg Chicares wrote:
[...]
>> - This class is rather fundamental to lmi, and is used pervasively,
>> so accidental pessimizations could be costly. That problem could be
>> avoided by extensive testing. Aside from what 'mc_enum_test.cpp'
>> covers, I'd be most concerned about bloating binary files and
>> increasing the time or the amount of RAM required to build them.
> 
> I mostly only refactored the code, so I don't think I affected compiler
> or runtime performance. I only make the assumption that the compiler
> will inline simple functions such as this one:
> 
>     static enums_t enums() { return *e; }
> 
> If it does, then runtime performance should be exactly same.

Comparing "new" (patched) to "old" (HEAD as of this moment)
shows almost no material difference:

                                       new        old    relative
timings:
  make mc_enum_types.o                  12.671     11.707  -7.6%
  compile mc_enum unit test             30.425     30.430  +0.0%
  compile all [`time make install`]  12:51.69    13:01.16  +1.2%
  make system_test                    5:19.62     5:14.10  -1.7%
  run input_test [.cns io]          4.499e-02   4.503e-02  +0.1%

Build times were recorded after 'make clean'. Most tests were run
repeatedly to avoid cache effects, the median of several runs being
recorded.

After building everything, including all unit tests, the size of
the build directory was ten MiB lower for "new", out of about
three hundred forty MiB. Apparently some template bloat was reduced
somehow--I don't think it's crucial to understand the exact cause
of this improvement. The largest relative change measured above is
the time to compile a file containing many mc_enum instantiations;
it's good to spend more time there, and less elsewhere, to get
smaller binaries.

> BTW, a question inspired by Vadim: should we have some form of automated
> tests to verify that too short or too long enum values/names list do in
> fact break compilation?

Ideally our unit-testing framework would support tests that aren't
supposed to compile (or to link). But we don't have much use for
that, and there's plenty of other work that has to take priority.