Some performance questions

[Lars Kyllingstad]

Daniel Keep wrote:
> 
> Lars Kyllingstad wrote:
>> [snip]
>> From a performance
>> perspective, however, it carries with it the overhead of an extra
>> function call, which I'm not sure I want.
>>
>> -Lars
> 
> You're worried about a second function call which could potentially be
> inlined, yet you're seemingly not worried about the overhead of virtual
> calls or heap allocations...

But that's the problem, you see. I don't know how expensive these 
operations are, hence my initial question(s). (This was also why I 
posted my question in D.learn.)

For instance, I didn't know (not sure I still do) what the cost is of 
frequent allocation/deallocation/access of stack memory vs. infrequent 
allocation/deallocation and frequent access of heap memory. From the 
replies I've got, it seems heap variables make for significantly slower 
code.

Nor was I sure, as you pointed out, how expensive a virtual function 
call is vs. an extra non-virtual function call.

I'm a physicist, not a computer scientist. :)

> Allow me to quote Donald Knuth:
> 
>> We should forget about small efficiencies, say about 97% of the time:
>> premature optimization is the root of all evil.
> 
> Unless you're doing something where you *know* you're going to need
> every last cycle, just go with whichever design works best.  Your
> response to Jarrett implies that you've already got a design in mind,
> and are just fishing for a magic "make it go faster button."

I want that button, yes. :)

But seriously, I am doing numerical computations, so performance is 
absolutely an issue. The main thing I wanted to know was, can I have 
both performance and usability, or do I have to choose? With Jarretts 
suggestion I can, to some degree, have both.

> Believe me, if Walter had invented such a thing, he wouldn't be wasting
> his time putting up with us; he'd be too busy smoking $100 bills from
> the comfort of his SPACE FORTRESS.  :D

What are you implying, that he wouldn't make it open-source? :)

> In any case, I'm willing to bet that if there *are* inefficiencies
> you're not going to know exactly where until you've written the code,
> anyway.  :P
> 
> If classes work, and make for an elegant design, go for it.
> 
>   -- Daniel