3 ms·
C's qsort() has a similar overhead vs C++ STL's std::sort() for much the same reason - the C version calls a comparator function but the C++ compiler can inline
by willvarfar 10y ago
C's qsort() has a similar overhead vs C++ STL's std::sort() for much the same reason - the C version calls a comparator function but the C++ compiler can inline the comparator.
- candiodari 10y agoAnd the only way to fix it without generics is with a VM.
- willvarfar 10y agoOr whole-program-optimisation or a compiler that has builtins for qsort() (rather as they all do for malloc/free these days)
- candiodari 10y agoI shudder at the thought of compilers with builtins for something as complex as qsort. But yeah, it would fit with Go's usual way of doing things.
- nieksand 10y agoIt seems like what amelius suggests in another thread would work too. I'm not advocating for this as desirable, but I'm thinking about the "possible" bit. It's basically the same as what a JIT compiler does around type inference. If it can reason about the underlying type that's really going to Sort(), it can code generate a specialized version. The machinery for escape analysis that Go already has probably gets you at least part of the way there. That pretty much boils down to a non-user-controllable templating done entirely through the compiler. Like I said... possible vs desirable.