←back to thread

271 points mithcs | 3 comments | | HN request time: 0.585s | source
Show context
kerkeslager ◴[] No.45954593[source]
I feel like there might be some value in this header file for some projects, but this is exactly the wrong use case.

> In cgrep, parsing command-line options the old way is a breeding ground for CVEs and its bestiary. You have to remember to free the memory on every single exit path, difficult for the undisciplined.

No, no, no. Command line options that will exist the entire lifetime of the program are the quintessential case for not ever calling free() on them because it's a waste of time. There is absolutely no reason to spend processor cycles to carefully call free() on a bunch of individual resources when the program is about to exit and the OS will reclaim the entire process memory in one go much faster than your program can. You're creating complexity and making your program slower and there is literally no upside: this isn't a tradeoff, it's a bad practice.

replies(3): >>45954628 #>>45955473 #>>45957515 #
JonChesterfield ◴[] No.45955473[source]
shouldn't be individually allocated either, arenas for the win
replies(1): >>45955729 #
1. kerkeslager ◴[] No.45955729[source]
I think that a blanket should/shouldn't recommendation for arenas isn't right. Arenas are a tradeoff:

Pros: preallocating one arena is likely faster than many smaller allocations.

Cons: preallocation is most effective if you can accurately predict usage for the arena; if you can't, then you either overshoot and allocate more memory than you need, or undershoot and have to reallocate which might be less performant than just allocating as-needed.

In short, if you're preallocating, I think decisions need to be made based on performance testing and the requirements of your program (is memory usage more important than speed?). If you aren't preallocating and just using arenas for to free in a group, then I'm going to say using an arena for stuff that is going to be freed by the OS at program exit is adding complexity for no benefit--it depends on your arena implementation (arenas aren't in the C standard to my knowledge).

In general, I'd be erring on the side of simplicity here and not using arenas for this by default--I'd only consider adding arenas if performance testing shows the program spending a lot of time in individual allocations. So I don't think a blanket recommendation for arenas is a good idea here.

EDIT: In case it's not obvious: note that I'm assuming that the reason you want to use an arena is to preallocate. If you're thinking that you're going to call free on the arena on program exit, that's just as pointless as calling free on a bunch of individual allocations on program exit. It MIGHT be faster, but doing pointless things faster is still not as good as not doing pointless things.

replies(1): >>45958628 #
2. lelanthran ◴[] No.45958628[source]
>If you aren't preallocating and just using arenas for to free in a group, then I'm going to say using an arena for stuff that is going to be freed by the OS at program exit is adding complexity for no benefit

What makes you think that the program is going to exit anytime soon?

Arenas are useful if you want to execute a complex workflow and when it is over just blow away all the memory it accumulated.

An HTTP server is the textbook example; one arena per request, all memory freed when the request is completed, but there's many many more similar workflows in a running program.

Leaving it for program exit is a luxury only available to those writing toy programs.

replies(1): >>46007931 #
3. kerkeslager ◴[] No.46007931[source]
> What makes you think that the program is going to exit anytime soon?

Because freeing memory in multiple exit paths of a short-running program is the definition of the problem he's trying to solve. Read what I posted before you waste everyone's time with another ego-based response where you don't admit you missed that important detail.

I'm well aware of what arenas are and they're an excellent tool for a lot of situations, maybe even most situations, but this isn't one of those situations.

Also be sure to let the authors of grep know their program used by millions of people is a toy program.