For the last year, Matus Goljer (fuco1) has been working on a static analyzer for Elisp. Although still in its early stages, the project is promising and I’ve been following it with interest. Goljer has made good progress and can now analyze the main file in the smartparens code base. There was a problem, however.
It was slow. Very slow. Analyzing smartparens took about 42 seconds even though the smartparens.el file is only about 9500 lines. Goljer was expecting it to be a bit slow because he used EIEIO and CL generics. While they’re a natural fit for the problem, they have notorious performance issues. What to do? Goljer did what we all do: he assumed the problem was with EIEIO and generics and started changing his code. That turned out to be a mess so he did what we all promise ourselves we’re going to do in situations like this but rarely actually do: he fired up the profiler to see were all the time was going.
The answer was surprising. The problem turned out to be in a function that he would never have thought would cause difficulties. I won’t spoil the surprise by telling you what it was; you’ll have to read his post to see. In any event, he replaced the problem function with some code that accomplished the same end and reduced the running time to 5 seconds.
The moral here is what it always is: don’t assume you know where all the cycles are being spent. You’re probably wrong. Almost every environment has a profiler and they’re the go-to method for determining where your application is spending its time.
Be sure to take a look at Goljer’s post. It’s an interesting story and a nice illustration of the power of profilers.