Elpher rendering speed

----------------------

At the risk of continuing the inanity which has plagued the last few

posts, I've just made an update to Elpher that I feel deserves a post

on its own.

Several people have mentioned (eg [1]) that Elpher can be a bit.. laggy.

Some of this no-doubt has to do with its line-by-line approach to

inserting text into the buffer when displaying gopher directories and

text/gemini documents, which is not easily avoidable. Some of it is

also likely to do with performing regexps over the text to identify

URLs, which I consider a key feature of Elpher and one which I'm

absolutely willing to sacrifice a bit of performance for.

Over the past few weeks however I've started to _really_ notice it.

This is probably because I've been browsing a bit more gemini, and

there tends to be a bit more of a lag there anyway due to the TLS

handshake. Again, likely unavoidable, but it managed to bring the

situation to my attention again and make me start to wonder what the

_real_ problem here was. The situation seemed _particularly_ bad on

link-heavy pages, such as [2]. Hrm.

So finally I fired up the profiler.

Oh yes, did you know - emacs has a built-in profiler for elisp? I

mean, of course it does. But still.

The profiler reports its results as a hierarchy of function calls with

some estimate of the %age of CPU time spent in each. The top level

results seemed in line with my intuition. Yes, it's the document

rendering function (87%). Yes it's the line rendering function within

that (still 87%). Hrm, interesting, it's the button-insertion function

within that (STILL 87%). (Emacs calls clickable text in buffers

"buttons".)

Hold on, what's this though? Within the button-insertion function a

function is called to generate the mouseover help-text, and _this_ is

using 87% of the CPU time. WTF??

Within that function, it turns out a single library function call to

url-encode-url (in order to provide nice normalized URLs in the

mouseover text) is using almost all of the CPU time in rendering this

particular link-heavy page. How embarrassing!!

Of course the first thing I try is just replacing the mousover text

with an empty string. My test page loads in a snap - basically an

order of magnitude improvement. The profiler wasn't lying!

Side note: fixing bugs and squashing performance bottlenecks like

this is absolutely the best part of programming! This is _so much

fun_! :-)

Even though I would have been happy to dispense with mouseover help

text entirely for such a performance boost, it turned out I didn't

have to. It's a common (and awesome) pattern in the Emacs elisp API

for certain variables/properties to accept either a function or a

string. The help-echo text property used by buttons has this feature.

I'd previously been filling each link button with a pre-generated help

text, but what I now do is to just use a reference to a

help-text-generating function instead. Thus the help text is

generated when it's needed rather than when the page is rendered.

(It's currently generated _every_ time it's needed - there's no

caching - but this isn't an issue as you don't need to rapidly read

mouseover texts over and over again.)

SO! As of 2.7.9, rendering speed is _significantly_ improved. The

improvement is so major that there don't even have to be _that_ many

links on the page to notice it. (For instance, my bookmarks page only

contains about 50 links and there used to be a ~0.25s pause every time

I visited it. To good approximation this is completely gone.)

Yay for profiling! (And boo to url-encode-url! Seriously, wow - so slow!)

--

[1]: https://www.emacswiki.org/emacs/CategoryGopher

[2]: gopher://cosmic.voyage/1/log