dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Thu, Sep 02, 2004 at 08:01:29AM -0700, Anders Logg wrote:
> ok, what does Johan J think?
> 
> /Anders
> 

I'm still thinking about the impact of having virtual functions (both
in the user-defined case, but also in the envelope-letter design). If
we are doing a redesign, now would be the time to consider this.

I'm still not sure about the magnitude of the overhead though. You can
find qualitative statements such as:

http://www-2.cs.cmu.edu/~gilpin/c++/performance.html

"Virtual functions negatively affect performance in 3 main ways:

1. The constructor of an object containing virtual functions must
initialize the vptr table, which is the table of pointers to its
member functions.

2. Virtual functions are called using pointer indirection, which
results in a few extra instructions per method invocation as compared
to a non-virtual method invocation.

3. Virtual functions whose resolution is only known at run-time cannot
be inlined.

...

The cost of using virtual functions is usually not a factor in calling
methods that take a long time to execute since the call overhead is
dominated by the method itself. In smaller methods, for example
accessor methods, the cost of virtual functions is more important.

...

Inlining is one of the easiest optimizations to use in C++ and it can
result in the most dramatic improvements in execution speed. The main
thing to know when using inlining is when you should inline a method
and when you shouldn't inline.
"

It's primarily #3 and the last paragraph that is relevant. The
evaluation of a Function is probably often a simple operation, and
perhaps the gain from inlining would be significant.

What we need is some quantitive information. 

This is one article I found, but I don't think it considers inlining:

http://portal.acm.org/citation.cfm?id=236338.236369

Perhaps it's not relevant. If the assembler spends most of its time
doing sparse matrix operations or something similar, then a 10-50%
efficiency gain in function evaluation might not matter. But if
evaluation functions (coefficients for example) is a significant cost,
then it might pay off to stay away from virtual functions.

Perhaps we can wait a couple of days more and try to figure this out a
bit more, perhaps do some benchmarks, then we can decide.

If we move away from virtual functions, then that will be quite a
significant design change, so there has to be some significant gain.

  Johan