Questionable use of `wiki#journal#get_all_nodes()`

[samgriesemer]

Description
Long-time wiki.vim user here. I recently updated an old fork of the plugin, and my :WikiJournalPrev/:WikiJournalNext calls have gone from nearly instantaneous execution to taking upwards of 5 seconds. Perhaps there are other new internals to blame, but this looks to be the fault of the wiki#journal#get_all_nodes() call in wiki#journal#go(). In my case, this entails matching 3000+ journal pages for each step through daily files (e.g., if I want to go from 2025-02-13.md to 2025-02-14.md), and appears to be done from scratch each call.

Is this a known drawback and experienced by others with 1000s of journal files? Any particular reason the logic has changed for this command (relative to ~1.5 years ago)? Would be happy to dive further if there's a planned change, but I've otherwise not done much more looking for the time being.

Here are my wiki_journal settings, in case that's useful:

  let g:wiki_journal = {
      \ 'frequency' : 'daily',
      \ 'date_format' : {
      \   'daily' : '%Y-%m-%d',
      \   'weekly' : '%Y-w%V',
      \   'monthly' : '%Y-m%m',
      \ },
  \}

I'm also using the latest version of wiki.vim in Neovim 0.10.4 on Arch linux.

Thanks @lervag for the great plugin and any help on this!

[lervag]

Just want to give a heads up that I've seen your issue and I will try to find time to look at it and respond as soon as possible.

[lervag]

Long-time wiki.vim user here. I recently updated an old fork of the plugin, and my :WikiJournalPrev/:WikiJournalNext calls have gone from nearly instantaneous execution to taking upwards of 5 seconds.

This is strange.

Perhaps there are other new internals to blame, but this looks to be the fault of the wiki#journal#get_all_nodes() call in wiki#journal#go(). In my case, this entails matching 3000+ journal pages for each step through daily files (e.g., if I want to go from 2025-02-13.md to 2025-02-14.md), and appears to be done from scratch each call.

I have >4000 journal pages, and it is (more or less) instantaneous on my end. But I'll look at it, perhaps I'm just "lucky" somehow. I'll see if I can find something that slows things down.

Any particular reason the logic has changed for this command (relative to ~1.5 years ago)?

Not that I'm aware of, no. There have been some substantial improvements the last years, but I'm not aware of any relevant regressions.

Here are my wiki_journal settings, in case that's useful:

I don't think it should be relevant, but I'll check. Perhaps the - instead of the _ (default) somehow makes things slower?

I'm also using the latest version of wiki.vim in Neovim 0.10.4 on Arch linux.

I strongly advice that you instead follow the latest main branch instead of the latest released version.

Thanks @lervag for the great plugin and any help on this!

I'm glad you like it, and thanks for posting your issue!

[lervag]

Can you update and test? I think I found two tricks that should make it fast again. There was a noticable improvement on my end, even if I claimed it was not laggy for me. When measuring I noticed that it indeed took O(0.5) seconds, now I'm down to O(0.01) seconds.