-
Notifications
You must be signed in to change notification settings - Fork 670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] improve graph performance #1391
Conversation
} | ||
} | ||
|
||
if (needle === '/page b.md') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to remove this ;-)
This is amazing @pderaaij ! I am back from holidays (you know, italy + august = holiday) so will look a bit more into the PR this week |
Sharing some high level thoughts here. What do you think? Again, this was at a cursory look, I might be missing something |
Never really looked into the trie datastructure. Will do some research and fiddle around! |
I need a bit more time to figure out the right approach. Have been looking into tie data structures, but most implementation I found are immutable. A characteristic we don't want for our use case here. So, I need to find an implementation that does allow mutations. Did a quick checkout of https://rimbu.org, but couldn't find a right data structure off the bat for our use case. So, I require some more time to look around and find a solution. Ideas welcome of course. |
I got a long way tonight using https://yomguithereal.github.io/mnemonist/trie-map. Need to finish some things and get the last use cases working. Will do a new performance test when things are working. Hopefully I can finish it later this week. |
@riccardoferretti I've updated the implementation with my WIP so far. It has a little impact on performance. Compared to the earlier version, I now load the I have one remaining issue and I hope you can help. Originally, a Map holds the insertion order. TrieMap obviously does not do that. But, this means that If we can resolve this issue, all tests will be green so we can do some further testing and enhancing before shipping it. |
c9c853e
to
ce662af
Compare
@riccardoferretti it seems I was on the right track, but simply not sharp after a long day of work. Got it working now. Please review and check accordingly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this is looking like the right approach, I left a few comments. Let me know what you think
this._resources.values() | ||
).sort(Resource.sortByPath); | ||
|
||
return resources.values(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need the .values()
again on this line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems so. The only way I can see to return an IterableIterator
@@ -70,17 +79,24 @@ export class FoamWorkspace implements IDisposable { | |||
} | |||
|
|||
public listByIdentifier(identifier: string): Resource[] { | |||
const needle = normalize('/' + identifier); | |||
let needle = this.getReversedIdentifier(identifier); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you moved the addition of \
from here into the getReverseIdentifier
fn. I wonder if there is any side effect from doing that?
Tbh, I am kinda relying on the tests passing here, I find this code (the existing one, that I wrote :) ) hard to properly process, I think at some point I will need a round to make it clearer for my future self and others :)\
I think fundamentally the semantics we want here is that resources can be found by either the identifier as is and by the identifier + default extension. Maybe we save both keys in the Trie.
In any case, just sharing some thoughts, I am ok with moving forward with the PR before sorting this out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far, I haven't found any side effect. I guess it was done originally to always have a start of a path.
I agree with optimising the logic on a next round. Also to solve #1399.
87807e9
to
958a03c
Compare
@riccardoferretti somehow I managed to break the build in CI. Locally all works, but can't get it going on Actions. Could you have a look? |
@pderaaij I think it's related to the markdown-it version change |
Yeah, I was hoping that would fix it. Had the problems after rebasing the lock files. Which was a hassle on its own.... |
Well... I found the little bugger: |
I am giving up on this PR. Going to do a fresh branch on master and open a new PR. Not trusting all the mess this has created. |
Based on some performance findings found #1375 I started to experiment with some improvements. I've noticed the function
listByIdentifier
being called alot by other functions. In this function, there is aforeach
loop running over all resources. A function which works fine for small notebooks, but large notebooks seems to be hit exponentionally.In this concept I've added a new state object that lists all resources for an identifier. In this case, I choose the identifier to be the file-name of the note. Using that identifier, I list all resource paths with that same identifier. Using this I can remove the
foreach
loop and just use the identifier to list a small set of resources.For the 10000 linked notes folder from this repo (https://github.com/rcvd/interconnected-markdown/tree/main/Markdown) this reduces the startup time to:
Using the current master the numbers are:
A delta of almost 25 seconds for loading the graph. Not only a performance improvement for loading the workspace, but also for some other operations that uses
listByIdentifier
directly or viafind
. This should make several UI components work better and more responsive.The downside is that it adds a new stateful object, but I don't see an other way to increase the performance of the foreach loop.
@riccardoferretti curious to your thoughts on this.