Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If 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.


It would still make sense to give a number or a range.


Depends, 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).


Performance is not the only important metric, and LoC is a good approximation to B complexity.


Since malloc() is a standard C library function, it would be okay to not count its implementation (which isn’t necessarily written in C).


If 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: