3 ms·
I had to read a little between the lines to understand your point, which I think is this: Even if you have an object type that requires only lowest-performance
by jstimpfle 7y ago
I had to read a little between the lines to understand your point, which I think is this: Even if you have an object type that requires only lowest-performance memory management (say, editor undo/redo items), you should separate these allocation concerns from all the other allocation concerns in the program, because you might risk contention. It's important to group allocations by lifetime.
To which I'll say, shouldn't we rather optimize and separate the high-bandwidth stuff, so we can keep using malloc-per-object for the unimportant stuff?
The rest of your comment does not apply to a simple undo/redo system:
> In some algorithms, 90-99%+ of runtime can be in allocation and freeing small objects!
> On top of that, accessing a sequential stack (array) is significantly faster. CPUs are built for that type of access patterns.
- geocar 7y agoNot the person you’re replying to, but: > shouldn't we rather optimize and separate the high-bandwidth stuff, so we can keep using malloc-per-object for the unimportant stuff? If it helps, sure, but one problem that shows up nasty at high bandwidth is variable latency: malloc might be too clever and vary on the order of msec and with hard-real-time environments you can’t amortise the cost over multiple messages since missing one means you never catch back up (without e.g. throwing data away)
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- ShroudedNight 7y agoI've only cursory exposure to it, but my understanding is that TLSF malloc[1] is designed to directly address those concerns. Is it known to be deficient such that its claims are invalid in / worthless for real-world use? [1] http://www.gii.upv.es/tlsf/files/ecrts04_tlsf.pdf http://www.gii.upv.es/tlsf/files/ecrts04_tlsf.pdf