Potential optimizations

[benfdking]

This is just a list of potential optimizations that we think could work.

Maintained list of optimizations

• We currently use random numbers (uuid) for our caching system, my understanding is that generating random numbers could be expensive (at the very least it's 128-bit), could you
  • 1. move to 64-bit integers
  • 2. not use random. but a counter, so it is more deterministic and skips expensive random
• Can we const fn more of the work upfront for building of dialects, (we could potentially use Perfect Hashes)
  • Could have an improvement on what is packaged
  • Could have an improvement impact on startup
• Are there any bits where we still use String and .clone() for convenience?
• Caching Depmath
• Caching dependent type set
  • We know we do these lazily/optionally on call; is it worth introducing that branching?
• A surprising amount of time is spent in DepthMap from_config. Could we "parse" the config into a super clean type first and then make the downstream "re-parsing" of every time from a slightly more flexible structure more efficient?
• Will building with --features=jemalloc improve performance?

@gvozdvmozgu feel free to add any comments that you have thought of

[gvozdvmozgu]

It seems that creating a DepthMap is currently quite expensive and is not cached, meaning different rules generate their own DepthMap for the same segments.

[gvozdvmozgu]

Using const fn is unlikely at the moment. We need at least compile-time HashMaps. There is an attempt to implement this in this PR, but it requires unstable features, and I’m not sure how well it actually works. The PR appears to be abandoned.

[benfdking]

I was also looking at some of the flame graphs, and to me, there may be two potential areas of improvement:

1. A descendant_type_set is a function where a lot of time is spent. Is there a way to speed it up descendant_type_set? We use AHashSet but since we are acting with very small sets, I wonder if just doing the comparison could be faster?
2. A surprising amount of time is spent in DepthMap from_config, could we "parse" the config into a super clean type first and then make the downstream, "re-parsing" of every time from a slightly more flexible structure more efficient.

[gvozdvmozgu]

Will building with --features=jemalloc improve performance?

[gvozdvmozgu]

the descendant_type_set should ideally be cached, at least that's how it's done in the original implementation

[gvozdvmozgu]

We use .to_uppercase (which allocates a String) in some places for case-insensitive comparison. Instead, we could use something like UniCase<Cow<'static, str>>. It appears we already use UniCase in some parts of the code. And accordingly, change the signature of Matchable::simple to Option<(AHashSet<UniCase<Cow<'static, str>>, AHashSet<&'static str>)> for example.

[benfdking]

Just thought I'd upload a latest flamegraph.

[Victorthedev]

Can i work on one of the remaining 3 tasks?

[benfdking]

Hey @Victorthedev, feel free to look at anything you think is valuable. Happy to support any contributions!

There's still lots to do but this may be slightly out of date. Some of the ideas are still right but I would definitely try recreating that flamegraph and seeing where the opportunities lie.