perf: checking the syntax contains/cluster list is slow#29
Conversation
h-east
commented
May 29, 2026
Measurement resultsBuild: ./configure default CFLAGS (-g -O2), no profiling. Method: clean A/B on the same binary using test_override('syn_idlist_cache',
in_id_list() self time drops from ~10.7% to ~6.6% (perf). The gain is largest Correctness: byte-for-byte identical synID() output with the cache on and off Tests: test_syntax (incl. a new Test_syntax_idlist_cache_unchanged differential Maintainability
Relationship to the lead-byte prefilter PR (vim#20371)This is a separate, complementary optimization: the prefilter speeds up |
ef0af30 to
256d550
Compare
64b37b3 to
32a75fe
Compare
719e174 to
9991544
Compare
32a75fe to
a883733
Compare
9991544 to
a40637c
Compare
a883733 to
04895db
Compare
a40637c to
2339b40
Compare
04895db to
fecd3d5
Compare
2339b40 to
d8e12d5
Compare
Problem: Deciding whether a group is in a "contains"/cluster list scans
the list and expands clusters on every check, which is slow for
syntaxes with large lists (e.g. plugins such as netrw).
Solution: Resolve each list once into a sorted, cluster-expanded set of
group IDs and use a binary search; cache it per syntax block and
drop the cache when syntax definitions change.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
d8e12d5 to
b0b17c2
Compare