Re: alloca / _alloca / dynamic stack memory
You have a bad habit: top posting. Get rid of it!
On 9 Mar., 22:26, Michael Crawley
<MichaelCraw...@discussions.microsoft.com> wrote:
The default new and delete operators are very slow..they hit malloc/free
somewhere, which are used to access a shared heap that all of the process=
's
threads compete over. There is usually a speed improvement if we can rem=
ove
some of this competition for a lock used within malloc/free.
How do you know that that is the case? Did you verify that the default
operator new does not use thread local storage?
In my opinion, you are doing the things upside-down: you assume that
something is slow and decide to optimise that part. But the reality is
that you have not tested the code to find out if new/delete is truly a
bottleneck.
As Knuth said: "Premature optimization is the root of all evil". Test
your code first and then replace the memory manager if that part seems
to take to long. Perhaps (probably!) the bottleneck will show up not
in new/delete but in some other location, and you will be able to
forget your hack.
/Peter
thread-exclusive heap (perhaps when it's needs memory it drafts from anot=
her
heap occasionally) is way faster than the default heap and is prefered ov=
er
my dynamic stack memory mechanism....
"peter koch" wrote:
On 8 Mar., 05:31, Michael Crawley <Michael
Craw...@discussions.microsoft.com> wrote:
I am trying to define a base class that will allow dynamic stack allo=
cation
for small types, amongst other things.
[snip]
Why? How expensive was heap allocation in your code? Did you measure
the time taken inside ::operator new and ::operator delete?
/Peter- Skjul tekst i anf=F8rselstegn -
- Vis tekst i anf=F8rselstegn -