Optimizing Generic Function Calls

[daninus14]

Hi,

I was just reading: https://scottlburson2.blogspot.com/2024/10/comparison-fset-vs-sycamore.html

With that change, the generic function overhead appears to be the only significant cause of the remaining ~20% performance difference.

I thought about this: https://github.com/marcoheisig/fast-generic-functions

Disclaimer: I've never used that project. Just wondering if maybe it can help speed up performance if this is something that is important to you.

Just wanted to share. Thanks for your contribution of FSet! 😄

[slburson]

Thanks for the suggestion. While that's nice work on Marco's part, it wouldn't help for this particular case. FSet's internal tree-manipulation routines, which are making frequent calls to the central generic function fset:compare, can't know the types of user data that are being compared — the whole point is that users can add new types.

There are places where FSet could benefit from this technique, but the gains would be small. I'm not sure it's worth the trouble. But maybe I'll take a closer look at some point.

However, since writing that blog post, I did add the option for users to supply a custom comparison function when creating a set, map, or bag. I believe that closes the gap with Sycamore (though I haven't re-run the benchmark; guess I should do that). See my more recent blog post, or the 1.5.0 release, for more info.

[daninus14]

Thanks for the reply! Will look for the blog post