feature(?): caching contents of backlinks buffer

[emacsomancer]

I wonder if it would be possible to (optionally) cache the output of the backlinks buffer (*org-roam* buffer).

Nodes with lots of backlinks (say around a 1000) take a couple of seconds even a fast machine, and on Android/Termux, this can take a couple of minutes (!). Could the actual output could be cached? (And then org-node-fakeroam--accelerate-get-contents could optionally fetch the cached content.)

Figuring out when to recalculate the backlinks would be tricky though. (Though maybe at least for changes that org-node knows about this could be managed somewhat [things that changed in the background wouldn't be caught, but that's perhaps an acceptable cost].)

Using org-node on Android/Termux has addressed a lot of the issues that I've faced in terms of slow speed[0] of org-roam operations, but backlinks remain an issue.

[0]: I think it's all down to Android's use of some sort of FUSE overlay file system (even for the real internal storage). Whatever the exact cause for the slowness, it's definitely about file-system access and not raw processing or anything.

[meedstrom]

Interesting idea. Yea, if the 1000 backlinks all come from different files... it'd have to get slow. That's like running org-node-backlink-fix-all or equivalent until you reach the 1000th file. Opening an Org buffer for each.

There is a dirty trick to "cache", though many users won't like it: leaving 1000 open buffers in the background ;)

[emacsomancer]

Ah, so you think the best way of "caching" would be just leaving the buffers open in the background? (I suppose this makes sense - the file system hits of actually accessing the files would occur if they're re-opened.) I was initially thinking of just saving the output of the *org-roam-buffer* in a hash table linked to the source node - is there any way for that to work?

The dirty trick method: could the buffers be renamed with space preceding their names? As I recall, doing that prevents them from showing up by default in ibuffer or the like.

The other downside of doing the "dirty cache" method would be that it wouldn't help when Emacs is closed and re-opened. (If the hash table cache method is viable, that could be made persistent across sessions if the cache was saved out.)

[meedstrom]

Ah, hidden buffers, that would a good trick. Unfortunately Emacs has a hard limit of 1024 open files, so it's really a no-go.

It does seem like org-node-fakeroam--accelerate-get-contents would be the place to do the caching. A hash table that saves the result should work. I foresee that the main issue is when to renew a given result :) I suppose a table of mtimes should sort that out.

[emacsomancer]

For the renewal issue - what about a function added to either org-node-insert-link or (perhaps better) org-node--handle-save which modified the saved "backlinks result buffer" cache for that node if a link was added that referenced that node? (That wouldn't deal with changes that happened outside of the current Emacs session, so wouldn't help in the case of synced files that changed, for instance, of course.)

[meedstrom]

Worried it'll be slow even to check 1000 mtimes? I'll bet you one euro it's not :)

I've been wanting to simplify org-node--try-launch-scan by using a table of mtimes, so it's great that it can have a secondary purpose.

[emacsomancer]

I don't know. Just trying to do find-file on Termux in a directory with a lot of files takes forever (like over 10 seconds). But I'm not sure of the method of checking mtimes, so I'm not sure.

[meedstrom]

If those are Org files, I think you're seeing the slowness of turning on Org-mode in each visited buffer, not the filesystem. Try renaming them all to .txt and doing the same experiment!

[emacsomancer]

But I just mean the time between calling find-file and the minibuffer opening up with the interactive find-file component. Not actually opening any of the files (though that is sometimes slow too, and maybe that slowness is contribute to by the result of modes like Org-mode turning on).

[meedstrom]

Oh ok. That's probably filesystem indeed.

So let's see...

Guessing this takes over 10 seconds?

(benchmark-run-compiled 1
  (directory-files-recursively
   (expand-file-name org-roam-dailies-directory
                     org-roam-directory)
   "."))

Then this takes... how long?

(benchmark-run-compiled 1
  (let ((files
         (directory-files-recursively
          (expand-file-name org-roam-dailies-directory
                            org-roam-directory)
          ".")))
    (dolist (file files)
      (file-attribute-modification-time (file-attributes file)))))

Second form takes my machine 20x longer than the first form. So be prepared :)

[emacsomancer]

The first results in:

(11.620225429000001 0 0.0)

[emacsomancer]

The second seems to be roughly the same:

(10.338752852999999 0 0.0)

(rerunning the first test, I get somewhere between 6-11 seconds, it seems. I'm guessing looking at the file-attribute-modification-time doesn't actually significantly affect things on the Termux/Android instance for whatever reason?)

[meedstrom]

Filesystems man...

Btw you spoke of general sluggishness. I'm guessing with a lot of things in Emacs. But also that M-x org-node-reset blocks Emacs for 11-19 seconds before it even starts scanning? And this is not shown in the time elapsed message at the end.

Alas, using a memoized result in that case would not be sane. Maybe the work of org-node-files (actually just renamed it to org-node-list-files) should be carried out in an external process :p

I saw in one of the printouts on #17, that you have org-node-perf-max-jobs automatically set to 1 on some of your devices? There could be room to improve org-node--count-logical-cores.

[emacsomancer]

Yes, I count 17 seconds for M-x org-node-reset on Android/Termux.

Why would using the memoised result then not be sane? Why would it require doing org-node-reset frequently?

I haven't manually touched org-node-perf-max-jobs anywhere, and both my one laptop and my phone report 7 for this variable. (Unless it's somewhere getting reset temporarily by something else??)

[meedstrom]

Ah. My bad then, I read the printout too quickly. The 1 in the backtrace line

  org-node--handle-finished-job(1 org-node--finalize-modified)

was just because there was only one file to scan. All good.

[meedstrom]

Why would using the memoised result then not be sane? Why would it require doing org-node-reset frequently?

In short, (org-node--scan-all) is where the magic happens whereby it finds IDs, new files, deleted files. Wouldn't be able to do that if it used a cached file list :)

The issue I foresee is that on your Termux setup (org-node--maybe-adjust-idle-timer) might get too optimistic. It sets an idle timer for this many seconds: (* 25 (1+ org-node--time-elapsed)). That would be fine if org-node--time-elapsed is 17 seconds, stretching the idle timer to over 7 minutes. But I guess it actually is 1 second or so? Then the timer will run after only 50 idle seconds, which then blocks Emacs for 17 seconds, long enough that you might notice it hung sometimes when you get back to the device...