What is the solution..?

[contactmayankjain]

Hi,

Its said that one should avoid dynamic allocation of memory, as it de-
fragment the memory into small chunks and allocation of memory is a
costly process in terms of efficiency. So what is the best solution to
handle to situation in which we need to allocate memory at run time.


Regards
Mayank Jain(Nawal)
(e-mail address removed)
9818390836

 

[Jim Langston]

Hi,

Its said that one should avoid dynamic allocation of memory, as it de-
fragment the memory into small chunks and allocation of memory is a
costly process in terms of efficiency. So what is the best solution to
handle to situation in which we need to allocate memory at run time.

using dynamic allocation of memory. use new

 

[contactmayankjain]

using dynamic allocation of memory. use new

How new is going to solve my problem. Are you trying to say use new
instead of malloc for allocating memory?
Regards
Mayank Jain(Nawal)
(e-mail address removed)
9818390836

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Hi,

Its said that one should avoid dynamic allocation of memory, as it de-
fragment the memory into small chunks and allocation of memory is a
costly process in terms of efficiency. So what is the best solution to
handle to situation in which we need to allocate memory at run time.

It depends on the situation, there is no perfect solution that will work
in all situations. I think that the advice is rather that one should
prefer automatic storage over dynamic when possible. However, one should
be aware that using automatic storage is not possible in all cases, in
fact most non-trivial applications will make use of dynamic memory,
either directly or indirectly via containers.

For some applications were objects of a certain kind needs to be
allocated and deallocated frequently a pool-allocator might increase the
performance and the effects of fragmentations is lessened.

 

[Scott McPhillips [MVP]]

Hi,

Its said that one should avoid dynamic allocation of memory, as it de-
fragment the memory into small chunks and allocation of memory is a
costly process in terms of efficiency. So what is the best solution to
handle to situation in which we need to allocate memory at run time.

Dynamic allocation is the ONLY solution to allocating memory at run time
(unless you use a language that provides garbage collection). If you have
problems with fragmentation then the only thing you can do is smarter
dynamic allocation, which requires knowledge of the allocation requirements
of your application.

 

[contactmayankjain]

Dynamic allocation is the ONLY solution to allocating memory at run time
(unless you use a language that provides garbage collection). If you have
problems with fragmentation then the only thing you can do is smarter
dynamic allocation, which requires knowledge of the allocation requirements
of your application.

What are the smarter way of allocating memory. I know the time and all
details about the memory requirement of my application. So how can it
help me in improving the efficiency of my code. Can you write a sample
code for this.
What is pool allocator?
Regards
Mayank Jain(Nawal)
(e-mail address removed)
9818390836

 

[Zachary Turner]

What are the smarter way of allocating memory. I know the time and all
details about the memory requirement of my application. So how can it
help me in improving the efficiency of my code. Can you write a sample
code for this.
What is pool allocator?
Regards
Mayank Jain(Nawal)
(e-mail address removed)
9818390836- Hide quoted text -

- Show quoted text -

I can answer this for you. Can you put me in touch with your
employer, so he can redirect your paychecks to me as well?

 

[Default User]

Hi,

Its said that one should avoid dynamic allocation of memory, as it de-
fragment the memory into small chunks and allocation of memory is a
costly process in terms of efficiency. So what is the best solution to
handle to situation in which we need to allocate memory at run time.

Why do you think it is a concern? Has this caused problems in your
current project?




Brian

 

[Bo Persson]

(e-mail address removed) wrote:
:: On Aug 20, 9:32 pm, "Jim Langston" <[email protected]>
:: wrote:
:::
::: :::
:::: Hi,
:::
:::: Its said that one should avoid dynamic allocation of memory, as
:::: it de- fragment the memory into small chunks and allocation of
:::: memory is a costly process in terms of efficiency. So what is
:::: the best solution to handle to situation in which we need to
:::: allocate memory at run time.
:::
::: using dynamic allocation of memory. use new
::
:: How new is going to solve my problem. Are you trying to say use new
:: instead of malloc for allocating memory?

He is saying that you should use new (and not malloc) to allocate
dynamic memory, if you need to do that. If you don't need dynamic
memory, you shouldn't allocate any.

The meaning of 'avoid' is "don't do it, unless you have to", not
"never do it".


Bo Persson

 

[werasm]

What is pool allocator?

Go to http://www.boost.org. They have some
implementations for pool allocators and explanations
of what it is.

Regards,

Werner

 

[Scott McPhillips [MVP]]

What are the smarter way of allocating memory. I know the time and all
details about the memory requirement of my application. So how can it
help me in improving the efficiency of my code.

There are decades of research on this. You could start with a Google search
for "low fragmentation heap"

 

[Jack Klein]

Hi,

Its said that one should avoid dynamic allocation of memory, as it de-
fragment the memory into small chunks and allocation of memory is a
costly process in terms of efficiency. So what is the best solution to
handle to situation in which we need to allocate memory at run time.

"It is said..." by whom? What makes you think this mysterious third
person source of information is correct?

If you do think this anonymous source is correct, ask he/she/it for
recommendations.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[tony_in_da_uk]

Dynamic allocation is the ONLY solution to allocating memory at run time
(unless you use a language that provides garbage collection).

Getting there. I would argue that dynamic allocation IS - by the very
meaning of the word dynamic - allocation at run-time. It's not just
the only solution, it is indivisibly the thing itself. "garbage
collection" only refers to one aspect of the myriad design and
implementation choices for algorithms offering dynamic memory
management.

If you have
problems with fragmentation then the only thing you can do is smarter
dynamic allocation, which requires knowledge of the allocation requirements
of your application.

Precisely.

Mayank: what's good depends a lot on the patterns of memory usage.

There are a couple distinct aspects.

Firstly: there's how often you need to do allocations. For example,
if you are having trouble inserting millions of elements in a
container, then see if there are functions to preallocate the required
space rather than grow during insertions, or at least to resize more
aggressively (e.g. resize arrays or hash tables by x4 instead of x2
each time more space is needed). How much can be done depends on the
container: for example, linked lists aren't likely to allow any kind
of pre-allocation.

Secondly: you can decrease the time needed for the allocations you
really can't avoid. To do this, follow suggestions elsewhere in this
thread, and use a custom allocator from boost.

So, to work out which direction to head down, you should profile your
application and work out which containers are causing you trouble,
during what kind of operations (insert, lookup, erase).

Taking a step back, in your original post:

Its said that one should avoid dynamic allocation of memory, as it de-
fragment the memory into small chunks and allocation of memory is a
costly process in terms of efficiency. So what is the best solution to
handle to situation in which we need to allocate memory at run time.

"It's said" suggests even looking at memory allocation may be a path
you've started on with no clear evidence from actual profiling. Did
someone at work tell you "this things slow, think it's the memory
allocation", and ask you to fix it? Don't believe them unless you see
hard evidence in the form of profiling results: you'll waste a lot of
time.

Cheers,

Tony

 

[Jerry Coffin]

Hi,

Its said that one should avoid dynamic allocation of memory,

It's said by whom? Offhand, this sounds like a generalization so broad
as to be almost insupportable. There may be circumstances under which
avoiding (at least some types of) dyanmic allocation is helpful, but
almost certainly others under which it is not.

as it defragment the memory into small chunks

That would be "fragment" rather than defragment. Defragmenting is the
process of taking small chunks and putting them together into larger
chunks again. Again, this sounds to me like a broad and insupportable
generalization.

and allocation of memory is a costly process in terms of efficiency.

More of the same -- the price of dynamic allocation varies widely
depending on quite a few factors, including the usage pattern(s) and the
policies used to manage the memory. Differeent allocation strategies
give different trade-offs between (for example) allocation speed and
keeping memory defragmented. Some do things like lazy coalescing, which
can improve average speed, but make a few allocations _much_ slower than
others. You can also trade off speed between allocation and freeing, as
well as between performance on different sizes and numbers of blocks
(i.e. some work better for allocating lots of small blocks while others
work better for a few large blocks -- some libraries switch between two
or three different strategies depending on block size).

So what is the best solution to
handle to situation in which we need to allocate memory at run time.

There is no one best solution, and so far it doesn't sound like there's
any real problem to fix anyway. My advice would be to use the default
implementation of new and delete to start with. Only when/if you find
that code is too slow, AND a profiler shows that allocating and freeing
memory is a bottleneck in the code should you consider using something
else.

When/if that happens, you'll probably need to look at the patterns of
your memory usage, such as patterns in allocating and freeing memory and
the relative uses of different block sizes to get a good idea of what's
likely to improve efficiency. My guess is that you'll never get to that
point though -- the amount of otherwise well-written code I've seen that
gained a lot by changing allocation strategy was pretty small. That's
not to say it couldn't happen, only to say that it's not really a good
bet that it'll necessarily be a problem.