7 ms·

A large difference. Random mallocs in library calls completely defeat the purpose of using C in the first place. Not only for performance but for fragmentation,

by dxhdr 13y ago

A large difference. Random mallocs in library calls completely defeat the purpose of using C in the first place. Not only for performance but for fragmentation, especially on embedded devices. It makes it impossible to use my own memory arenas and instead takes the lazy route of allocating from the global heap. Look at Jsmn for an example of how to do this sort of thing beautifully and cleanly with no global side effects.

Demiurge 13y ago
What do you mean by 'own memory arena' and what is the performance (or other) difference between that and global heap?
- alexchamberlain 13y ago
  Malloc often involves a context switch to kernel mode to grab more memory. This has improved, but still doesn't address the fragmentation issue.
- vidarh 13y ago
  Consider that you know that certain data is always de-allocated together. An example is when a document is opened and then closed. In that case you can make a dramatic amount of difference with arenas: Often you can avoid almost any memory overhead. E.g. any structures that are allocated on opening a document, and deallocated on closure, can be allocated from larger buffers without keeping any information about the individual allocations. That can save anything up to 16-20 bytes per allocation with many malloc() implementations, and reduces typical allocation cost to incrementing a pointer and checking whether or not you need to allocate a new buffer (and the allocation cost for new buffers might be amortised over anything up to thousands of small allocations). For a practical example, there's a font library that calls malloc() to allocate structures for every single glyph when opening a font. Most of the (thousands) of allocations are 4-8 bytes. Changing that to using an arena for an application I did, cut memory usage per font to about 25%-30% and cut load time for fonts to <10% by avoiding the malloc() calls. You can achieve the same by throwing abstractions out the window and putting stuff in arrays etc. But arenas is often a very effective way of keeping the abstractions while effectively getting almost the same performance and memory usage.
  - Demiurge 13y ago
    Ok, thanks for the example! I'm surprised it makes such a difference.
codehero 13y ago
Jsmn is a fresh (somewhat copout) approach, but unless you know the size of your JSON a priori (ie memory mapped file), I would hard call it beautiful or without global side effects. If you're into C++, take a look at benejson's pull parser. There is a C core but its presently very ugly and only intended for library, not application developers. http://codehero.github.io/benejson/ http://codehero.github.io/benejson/
cjh_ 13y ago
Thank you for mentioning jsmn, it was very enjoyable to read through jsmn's code.

by dxhdr 13y ago

Demiurge 13y ago

What do you mean by 'own memory arena' and what is the performance (or other) difference between that and global heap?

alexchamberlain 13y ago
Malloc often involves a context switch to kernel mode to grab more memory. This has improved, but still doesn't address the fragmentation issue.
vidarh 13y ago
Consider that you know that certain data is always de-allocated together. An example is when a document is opened and then closed. In that case you can make a dramatic amount of difference with arenas: Often you can avoid almost any memory overhead. E.g. any structures that are allocated on opening a document, and deallocated on closure, can be allocated from larger buffers without keeping any information about the individual allocations. That can save anything up to 16-20 bytes per allocation with many malloc() implementations, and reduces typical allocation cost to incrementing a pointer and checking whether or not you need to allocate a new buffer (and the allocation cost for new buffers might be amortised over anything up to thousands of small allocations). For a practical example, there's a font library that calls malloc() to allocate structures for every single glyph when opening a font. Most of the (thousands) of allocations are 4-8 bytes. Changing that to using an arena for an application I did, cut memory usage per font to about 25%-30% and cut load time for fonts to <10% by avoiding the malloc() calls. You can achieve the same by throwing abstractions out the window and putting stuff in arrays etc. But arenas is often a very effective way of keeping the abstractions while effectively getting almost the same performance and memory usage.
- Demiurge 13y ago
  Ok, thanks for the example! I'm surprised it makes such a difference.

codehero 13y ago

Jsmn is a fresh (somewhat copout) approach, but unless you know the size of your JSON a priori (ie memory mapped file), I would hard call it beautiful or without global side effects. If you're into C++, take a look at benejson's pull parser. There is a C core but its presently very ugly and only intended for library, not application developers. http://codehero.github.io/benejson/ http://codehero.github.io/benejson/

cjh_ 13y ago

Thank you for mentioning jsmn, it was very enjoyable to read through jsmn's code.