Re: Price of Creating Local Objects
From: David Hilsee (davidhilseenews_at_yahoo.com)
Date: 08/13/04
- Next message: Casper: "structs ALWAYS on the stack?"
- Previous message: Casper: "Re: Tree in C++"
- In reply to: cppaddict: "Re: Price of Creating Local Objects"
- Next in thread: Dave Townsend: "Re: Price of Creating Local Objects"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 13 Aug 2004 00:05:04 -0400
"cppaddict" <hello@hello.com> wrote in message
news:ttdoh0hr2he6lovcu3v3mjigtdrcglujcu@4ax.com...
> >How large is large? 50 bytes? 1 kilobyte? 1 megabyte?
>
> About 1 kilobyte.
That's probably nothing to be concerned about. I've dealt with C programs
that, in nearly every function, allocated around 500 bytes just for a
temporary sprintf() buffer.
> >In general, variables that are declared locally within a function are
> >allocated quickly. If the object were monstrous, then I could see how
one
> >might want to avoid declaring it as a local variable to a function, but
that
> >generally deals with issues of <implementation>stack
space</implementation>.
> >I wouldn't worry too much about what actually happens. Instead,
concentrate
> >on questions like "How fast is it?"
>
> I was hoping to get a feel for "How fast is it?" by understanding what
> goes on behind the scenes. Of course, I could just time it and see,
> but then I would have no insight. I'm actually pretty sure that speed
> would not be an issue, but only because I vaguely know that vaguely
> similar code has executed quickly.
If you really want to know exactly what is going on behind the scenes, you
should examine the implementation. If you're more interested in how fast it
executes, then measurements will be more helpful. In general, it is
relatively quick, because local variables usually result in some fiddling
with the stack, which is usually a cheap operation. Of course, any comments
mentioning to a "stack" are referring to a possibly common implementation.
> > If you're concerned that
> >the program might fail because the object is not a static member of a
class,
> >then, by all means, consult the implementation.
>
> That is not a concern. Is there any reason you think it should be?
Well, as I mentioned before, there can be a "stack space" exhaustion issue,
but that's not usually a problem for most applications. It's more of a
problem for applications that use highly recursive algorithms.
-- David Hilsee
- Next message: Casper: "structs ALWAYS on the stack?"
- Previous message: Casper: "Re: Tree in C++"
- In reply to: cppaddict: "Re: Price of Creating Local Objects"
- Next in thread: Dave Townsend: "Re: Price of Creating Local Objects"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|