Re: eon performance regression

[Paolo Carlini <pcarlini at unitus dot it>]

Andreas Jaeger wrote:

> Paolo Carlini <pcarlini@unitus.it> writes:
>
> > Andreas Jaeger wrote:
> >
> >> I don't think so, a grep for "std::string" revealed no matches.  eon
> >> is old and can even be compiled with gcc 2.95.x
> >
> > ... sorry for the trivial curiosity: did you also grep for "string", without std::?
>
> Nope, here's the result:
>
> eon.cc:#include <string.h>
> ggErr.cc:#include <string.h>
> ggIO.cc:#include <string.h>
> ggIOhdr.h:#include <string.h>
> ggIOhdr.h:                                // this is the length of the string
> ggRasterSurfaceTexture.cc:#include <string.h>
> ggString.cc:#include <string.h>
> ggString.h:#include <string.h>
> mrScene.cc:#include <string.h>
>
> What else do you want to know?

Thank you. I think we are making progress. This is the inclusion of a C header file (you
know it far better than me!), and in fact, if that is all grep gives you, there are *no*
declarations of C++ string variables!

This means that mine and Loren's patch, affecting the C++ string class, cannot be
responsible ;-)

Remains open the possibility of something strange going on with Benjamin's patch, which,
however, if I understand well, was meant to be just cleanup...

Do you have any wat to let us know how much time is in fact spent by the code in actual
I/O operations? (I know, in principle those tests are CPU/MEMORY bound but...)

Perhaps, something weird is going on with inlining at -O3 ?!?

Thanks,
Paolo.