5 ms·
This was quite interesting, but I’m disappointed it didn’t mention how many lines in C it actually took to run. Perhaps a profiler might help calculate this?
by BD103 3y ago
This was quite interesting, but I’m disappointed it didn’t mention how many lines in C it actually took to run. Perhaps a profiler might help calculate this?
- whizzter 3y agoIf you read the article you can see that some codepaths can invoke Malloc with all the follow-on effects like Kernel boundary crossings that this implies, it's thus quite random.
- serial_dev 3y agoIt would still make sense to give a number or a range.
- whizzter 3y agoDepends, I look at it from a performance standpoint when starting to count lines/instructions, not just directly executed code but also how feasible it would be to translate the thing to a JIT for example, the amount is large enough that going to a JIT would yield little (this is why there has been so many Python JIT's that has failed to gain enough performance and hence traction) before mayor architectural fixes are made. Not only is there branches to a ton of special things but also macros that hides even more lines (IncRef/DecRef probably has a lot of magic behind there).
- serial_dev 3y agoPerformance is not the only important metric, and LoC is a good approximation to B complexity.
- layer8 3y agoSince malloc() is a standard C library function, it would be okay to not count its implementation (which isn’t necessarily written in C).
- whizzter 3y agoIf only counting simple lines of code, malloc is often large enough of a beast that the code executed beyond that simple line often dwarfs the rest.