This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] replace malloc with a decl on the stack


On 11/12/13 05:41, Marc Glisse wrote:
On Tue, 12 Nov 2013, OndÅej BÃlka wrote:

I am trying to get something to actually work and be accepted in
gcc. That may mean being conservative.

That also may mean that you will cover only cases where it is not needed.

A malloc will have a small per-thread cache for small requests that does
not need any locking. A performance difference will be quite small and
there may be a define which causes inlining constant size mallocs.

Sizes from 256 bytes are interesting case.

I have to disagree here. When the allocated size is large enough, the
cost of malloc+free often becomes small compared to whatever work you
are doing in that array. It is when the size is very small that speeding
up malloc+free is essential. And you are underestimating the cost of
those small allocations.
I have to agree with Marc here. Start with something small and we can always look to extend it to handle more cases over time.

The whole point is to avoid going into the allocator which can be damn expensive. Allocating on the stack is orders of magnitude cheaper. If you can collapse down to a _DECL, then, well, that's the holy grail.

[soapbox]
And doing this kind of thing intelligently is something I strongly would encourage. I can't express my disdain for folks directly using alloca. Programmers have consistently shown they are unable to do so in a safe manner. The amount of time I have personally had to dedicate to dealing with the fallout from such practices is absurd.

Banning alloca in favor of malloc is something every project should seriously consider. Having the ability for the compiler to intelligently and safely take a malloc/free pair and turn that into alloca or DECL reference removes one more reason for programmers to directly use alloca.
[/soapbox]

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]