JS speed - Konq vs. Mozilla

[Koos Vriezen]

On Wed, 4 Sep 2002, Koos Vriezen wrote:

> On Wed, 4 Sep 2002, David Faure wrote:
>
> > > > > Real speed gain should be found elsewhere. A gprof output for the tested
> > > > > script, posted earlier in this thread, shows that KJS::Value::~Value() is
> > > > > called 299335 and KJS::Value::imp() 356709 times!
> > > >
> > > > Shouldn't those be inlined, simply?
> > >
> > > Would it not break BC (value.h is installed)?
> >
> > No. Old code would still call the method, new code would benefit from being
> > able to copy its contents. AFAIK this is no problem.
>
> Can't see any speed gain with inlining KJS::Value::imp(),
> KJS::Value::type(), KJS::Value::isNull() and
> KJS::Value::Value(const Value&).

However I do see a speed increase when compiling with -finline. KJS
becomes 10% faster with it. Inlining the above, it even becomes faster.
Could it be that gcc hits the inline limit? From 'man g++':
       -finline-limit=n
           By default, gcc limits the size of functions that can
           be inlined.  This flag allows the control of this
           limit for functions that are explicitly marked as
           inline (ie marked with the inline keyword or defined
           within the class definition in c++).  n is the size of
           functions that can be inlined in number of pseudo
           instructions (not counting parameter handling).  The
           default value of n is 600.  Increasing this value can
           result in more inlined code at the cost of compilation
           time and memory consumption.  Decreasing usually makes
           the compilation faster and less code will be inlined
           (which presumably means slower programs).  This option
           is particularly useful for programs that use inlining
           heavily such as those based on recursive templates
           with C++.

Koos