5 ms·

C doesn't require you to use qsort, the only thing that makes qsort common is that it is available in the standard library, but there are other libraries that p

C doesn't require you to use qsort, the only thing that makes qsort common is that it is available in the standard library, but there are other libraries that provide a faster approach, e.g. SGLIB[0] uses a macro-based approach where the code and comparison can either be inlined with the code or define functions for sorting specific types[1]. There are other libraries that do the same, another one was posted here recently. And of course, if needed, it can be implemented by the programmer. IMO the issue with the given Postgres example isn't that it is written in C therefore it is slow, it is why it doesn't use all of C's features to make it faster (assuming there is a real performance issue here - it is very possible that the Postgres authors didn't consider it a real issue until now). [0] http://sglib.sourceforge.net http://sglib.sourceforge.net [1] http://sglib.sourceforge.net/doc/index.html#array_exam http://sglib.sourceforge.net/doc/index.html#array_exam

gpderetta 4y ago
You can certainly do static polymorphism with macros in C, it is just very painful and unpleasant.
- badsectoracula 4y ago
  You don't need to do it all the time - or at all - just for the few things that can be performance sensitive (assuming the only reason you'd care is about performance and not, e.g. type safety) and that after you've actually figured out there is a performance issue that can only be solved with such an approach. After all while the linked article's author seem to present it as a problem that it took 25 years for this to be fixed, another way to see it is that it took 25 years for this to be an issue for someone to bother enough to try and fix it.
deleted 4y ago
[deleted]
RcouF1uZ4gsC 4y ago
> IMO the issue with the given Postgres example isn't that it is written in C therefore it is slow, it is why it doesn't use all of C's features to make it faster I think the issue the author is pointing out is that, in the real world, this real-life (fairly obvious) performance improvement was enough of a pain in C, that it was not done for 25 years. In languages with generics, this improvement would have come for free. With C, yes you can do the improvement, but you have to do it by hand, and you have now to maintain and debug multiple versions of sort.
- cozzyd 4y ago
  Well, as parent noted, you can use sglib, or implement your own thing in a similar manner (it's not that hard, sglib.h is very readable...).
- badsectoracula 4y ago
  > was enough of a pain in C, that it was not done for 25 years As i wrote in another reply, that might be one way to read the situation - especially if you want to create a narrative where languages like C without generics have inherent faults - but another way is that it was there for 25 years because it wasn't an actual problem in practice so nobody bothered to fix it until now.
  - ayende 4y ago
    4% - 6% overall query time improvement? That is absolutely an actual problem that is very attractive to solve. You'll see database people jump through far bigger hoops to get much smaller improvements.
msbarnett 4y ago
> IMO the issue with the given Postgres example isn't that it is written in C therefore it is slow, it is why it doesn't use all of C's features to make it faster (assuming there is a real performance issue here - it is very possible that the Postgres authors didn't consider it a real issue until now). Right, but that's kind of missing the author's point, which isn't "things that are written in C are slow" so much as "because C lacks generics and has a relatively-inefficient standard library implementation based on function pointers, most implementations do not take the extra steps of 'using all of C's features' to do something faster (because it's a lot of work, and the standard implementation exists)". It's mostly just an argument that generic-lacking languages make it easier to do something slower than something faster, and most people and projects follow the path of least resistance. That there are more efficient implementations available if you sink more effort into it isn't in dispute.
- badsectoracula 4y ago
  But at that point it isn't C's fault but the developer's fault for not using C's features. And of course assuming there is a fault in the first place (i.e. performance issue that actually matters in practice).

gpderetta 4y ago

You can certainly do static polymorphism with macros in C, it is just very painful and unpleasant.

badsectoracula 4y ago
You don't need to do it all the time - or at all - just for the few things that can be performance sensitive (assuming the only reason you'd care is about performance and not, e.g. type safety) and that after you've actually figured out there is a performance issue that can only be solved with such an approach. After all while the linked article's author seem to present it as a problem that it took 25 years for this to be fixed, another way to see it is that it took 25 years for this to be an issue for someone to bother enough to try and fix it.

deleted 4y ago

[deleted]

RcouF1uZ4gsC 4y ago

> IMO the issue with the given Postgres example isn't that it is written in C therefore it is slow, it is why it doesn't use all of C's features to make it faster I think the issue the author is pointing out is that, in the real world, this real-life (fairly obvious) performance improvement was enough of a pain in C, that it was not done for 25 years. In languages with generics, this improvement would have come for free. With C, yes you can do the improvement, but you have to do it by hand, and you have now to maintain and debug multiple versions of sort.

cozzyd 4y ago
Well, as parent noted, you can use sglib, or implement your own thing in a similar manner (it's not that hard, sglib.h is very readable...).
badsectoracula 4y ago
> was enough of a pain in C, that it was not done for 25 years As i wrote in another reply, that might be one way to read the situation - especially if you want to create a narrative where languages like C without generics have inherent faults - but another way is that it was there for 25 years because it wasn't an actual problem in practice so nobody bothered to fix it until now.
- ayende 4y ago
  4% - 6% overall query time improvement? That is absolutely an actual problem that is very attractive to solve. You'll see database people jump through far bigger hoops to get much smaller improvements.

msbarnett 4y ago

> IMO the issue with the given Postgres example isn't that it is written in C therefore it is slow, it is why it doesn't use all of C's features to make it faster (assuming there is a real performance issue here - it is very possible that the Postgres authors didn't consider it a real issue until now). Right, but that's kind of missing the author's point, which isn't "things that are written in C are slow" so much as "because C lacks generics and has a relatively-inefficient standard library implementation based on function pointers, most implementations do not take the extra steps of 'using all of C's features' to do something faster (because it's a lot of work, and the standard implementation exists)". It's mostly just an argument that generic-lacking languages make it easier to do something slower than something faster, and most people and projects follow the path of least resistance. That there are more efficient implementations available if you sink more effort into it isn't in dispute.

badsectoracula 4y ago
But at that point it isn't C's fault but the developer's fault for not using C's features. And of course assuming there is a fault in the first place (i.e. performance issue that actually matters in practice).