3 ms·
Not 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 un
by geocar 7y ago
Not 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