[sldev] Question on Overuse of virtual in C++

[Dirk Moerenhout]

Not yet, I'm still working on the consequences of the change resulting
from the below. I just removed all the virtuals except for the
destructor (it's the only virtual that will have an effect on how
stuff gets executed).

The result of getting inlined functions is that it's now more clear
who is doing all the calls as the cycles shift towards the caller. It
hence reduces fragmentation in the top consumers. As such it's
becoming easier to identify some of the top targets for improvement.

I'm using Event Based Profiling in CodeAnalyst and hence I not only
see the hotspots but also other info like IPC. Low IPC helps
identifying similar cases as IPC drops a lot if  you've too much
"overhead" instructions. So I guess I'll try to weed out some more
over-use (if possible).

Resulting patches will be split in order to have clear split for each
on what they touch. I was near to testing something yesterday evening
when somebody decided to swith to 18.0.0.4 just when I wanted to do
the next profile :) I'll hence migrate to 18.0.0.4 first and then
continue.

FYI: I've also tried to experiment with the heap but enabling LFH has
not yet proven to be that useful. I'm now considering whether we
shouldn't guide some of the vector usage. We can cut down on
allocations if we avoid the need to grow/shrink memory allocation too
much.

Dirk aka Blakar Ogre

On 7/6/07, Nicholaz Beresford <nicholaz at blueflash.cc> wrote:
>
> Dirk,
>
> did you find more of those virtualy in performance senstitiv
> areas of the viewer?
>
>
> Nick
>
>
> Dirk Moerenhout wrote:
> > For starters: I'm no C++ guru so I might be missing something. Feel
> > free to enlighten me if so ;-)
> >
> > My question is the following:
> > Is there a purpose to declare a function virtual if you've no
> > intention to overload it? As an example I'd like to take LLTreeNode.
> >
> > In LLTreeNode we've "virtual LLTreeListener<T>* getListener(U32 index)
> > const { return mListeners[index]; }"
>
>