Maxim Nikulin <maniku...@gmail.com> writes: > I could not guess how to benchmark font-lock. I have tried to open file > (to get everything loaded), kill the buffer,
I usually just use profiler-start/open buffer/profiler-report. However, there is also https://github.com/Lindydancer/font-lock-profiler for more fine-grained benchmark. Also, you may instrument org-activate-links with elp.el (built-in). > but I see some changes in the buffer after 0.19 is reported (both with > and without the patch). However I have not converted bracketed links > into plain ones yet. I was going to try if some tricks could improve > performance. E.g. I am curious if it will work noticeably faster when no > nested parenthesis are allowed, but single ones may be at any position, > not necessary at the end. I am currently looking into somewhat orthogonal approach. Instead of tweaking individual regexps (there were similar issues with priority regexp in the past), I am trying to use custom font-lock-fontify-region-function. Once we avoid fontifying folded text, startup time drops several times at least. I can see the difference immediately. It comes at the cost though - the behaviour of some Org API functions changes. They will not always return fontified text. AFAIK, at least helm-org and helm-org-ql do reply on such fontification. > Are changes in white spaces below actually modified lines in your patch > intended? They are generated by aggressive-indent. Since org files mix indentation styles I keep getting those whitespace changes in my patches. Forgot to remove this time. Should I? Best, Ihor
