Jarrett Billingsley wrote:
On Tue, Feb 3, 2009 at 3:44 PM, Chris Nicholson-Sauls
wrote:
The
second reason, is that before every allocation the garbage collector will
perform a collection run. This can actually be disabled (at least in
theory) if you plan on doing several allocations in a short
On Tue, Feb 3, 2009 at 3:44 PM, Chris Nicholson-Sauls
wrote:
> The
> second reason, is that before every allocation the garbage collector will
> perform a collection run. This can actually be disabled (at least in
> theory) if you plan on doing several allocations in a short period of time,
> and
Chris Nicholson-Sauls wrote:
Lars Kyllingstad wrote:
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 coul
Lars Kyllingstad wrote:
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
Lars Kyllingstad:
> I merely wanted to know if the second solution would be significantly slower
> than the first one.<
No amount of theory can replace actual timings of your code snippets :-)
(It's often true the other way too, practice doesn't replace theory. But here
there isn't too much theo
On Mon, Feb 2, 2009 at 4:55 PM, grauzone wrote:
> I agree. Of course using an interface to call a method always requires a
> virtual method call. It's even slower than a virtual method call, because it
> needs to convert the interface reference into an object reference.
>
> But he still could call
I agree. Of course using an interface to call a method always requires a
virtual method call. It's even slower than a virtual method call,
because it needs to convert the interface reference into an object
reference.
But he still could call the method in question directly. Implementing an
int
Jarrett Billingsley wrote:
On Mon, Feb 2, 2009 at 1:27 PM, grauzone wrote:
Why not use scope to allocate the class on the stack?
For everything else, I agree with Donald Knuth (if he really said that...)
That's fine too, and would fit in with his needs to implement
interfaces. But again, if
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 worr
On Mon, Feb 2, 2009 at 3:37 PM, grauzone wrote:
> As far as I know, interface methods can still be final methods in a class.
> final methods are only disallowed to be overridden further. But it's
> perfectly fine to mark a method final, that overrides a method from a super
> class. final so to sa
Jarrett Billingsley wrote:
On Mon, Feb 2, 2009 at 3:11 PM, Chris Nicholson-Sauls
wrote:
Or he's caching some very big/complex parameters in the code he's actually
writing... maybe. That said: do we have any assurance that, were the functor
class tagged as 'final', the call would cease to be vir
On Mon, Feb 2, 2009 at 3:11 PM, Chris Nicholson-Sauls
wrote:
>
> Or he's caching some very big/complex parameters in the code he's actually
> writing... maybe. That said: do we have any assurance that, were the functor
> class tagged as 'final', the call would cease to be virtual? If so, then
> t
On Mon, Feb 2, 2009 at 3:11 PM, Chris Nicholson-Sauls
wrote:
> do we have any assurance that, were the functor
> class tagged as 'final', the call would cease to be virtual?
http://d.puremagic.com/issues/show_bug.cgi?id=1909
Jarrett Billingsley wrote:
On Mon, Feb 2, 2009 at 1:27 PM, grauzone wrote:
Why not use scope to allocate the class on the stack?
For everything else, I agree with Donald Knuth (if he really said that...)
That's fine too, and would fit in with his needs to implement
interfaces. But again, if
On Mon, Feb 2, 2009 at 1:27 PM, grauzone wrote:
> Why not use scope to allocate the class on the stack?
> For everything else, I agree with Donald Knuth (if he really said that...)
That's fine too, and would fit in with his needs to implement
interfaces. But again, if he's worried about caching
Jarrett Billingsley wrote:
On Mon, Feb 2, 2009 at 8:31 AM, Lars Kyllingstad
wrote:
I have some functions for which I want to find the nicest possible
combination of performance and usability. I have two suggestions as to how
they should be defined.
"Classic" style:
real myFunction(real arg
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
Chris Nicholson-Sauls wrote:
Lars Kyllingstad wrote:
I have some functions for which I want to find the nicest possible
combination of performance and usability. I have two suggestions as to
how they should be defined.
"Classic" style:
real myFunction(real arg, int someParam, inout real
Jarrett Billingsley wrote:
On Mon, Feb 2, 2009 at 8:31 AM, Lars Kyllingstad
wrote:
I have some functions for which I want to find the nicest possible
combination of performance and usability. I have two suggestions as to how
they should be defined.
"Classic" style:
real myFunction(real arg
Lars Kyllingstad wrote:
I have some functions for which I want to find the nicest possible
combination of performance and usability. I have two suggestions as to
how they should be defined.
"Classic" style:
real myFunction(real arg, int someParam, inout real aReturnValue)
{
de
On Mon, Feb 2, 2009 at 8:31 AM, Lars Kyllingstad
wrote:
> I have some functions for which I want to find the nicest possible
> combination of performance and usability. I have two suggestions as to how
> they should be defined.
>
> "Classic" style:
>
>real myFunction(real arg, int someParam, i
Lars Kyllingstad wrote:
real anotherReturnValue;
Correction:
real aReturnValue;
I have some functions for which I want to find the nicest possible
combination of performance and usability. I have two suggestions as to
how they should be defined.
"Classic" style:
real myFunction(real arg, int someParam, inout real aReturnValue)
{
declare temporary variables
23 matches
Mail list logo
