search

WorldBrain / Memex

Browser extension to curate, annotate, and discuss the most valuable content and ideas on the web. As individuals, teams and communities.
https://worldbrain.io
4.41k stars 335 forks source link

Performance Issues of Memex #658

Open blackforestboi opened 5 years ago

blackforestboi commented 5 years ago

Myself and also a couple of users coming to our chats experience performance issues with Memex. We should address them as soon as possible.

1) #640 2) On tab changes it can happen that the page lags. Sometimes you see a white screen before the tab is properly loaded. Especially when the user has a couple of tabs open. How many processes do we load immediataly on tab-change, and how many can we maybe delay until the page has loaded? 3) Related to 2) and 1) we may have to think about a better way to queue processing, or delay the indexing to a point where there is less load on the system overall. 4) Memex actually starts to suck in quiet a bit of RAM now. In an idle state it has about 500mb for me and adding about 25mb for every new page I visit. So I am wondering 1) where that comes from and 2) how we can reduce that? If we now move to the shadowDom, but implement it with react, would that react component not also take up quiet some ram? https://developers.google.com/web/tools/chrome-devtools/memory-problems/

ShishKabab commented 5 years ago

We'd have to profile how much memory React uses on each page. Shadow DOM will reduce memory vs. iFrame, but does not increase memory overhead otherwise. If React turns out to use too much memory (very well possible, because the Ribbon is on every page), we can replace it with the minimal ultra-fast state management component I created for the direct linking page, so the code stays clean.

blackforestboi commented 5 years ago

AFAIK, the ribbon is unmounted for every tab that is not active, so it would not produce that overhead, no? Correct @mohitsakhuja?

iammohitsakhuja commented 5 years ago

Partially, yes. The ribbon itself isn't unmounted, however the iframe inside it and the sidebar inside that iframe are unmounted. You can see it in action if you open two tabs side by side and open Dev tools for each one. Then open the sidebar for any one tab and close it. You'll see that the iframe for that tab does not unmount just yet (I did not change this logic when I was working with code related to tab switching). Now when you switch to the other tab, the iframe from the old tab will get unmounted and a new iframe will get mounted in the new tab.

ShishKabab commented 5 years ago

The iFrame loading/unloading is a clear optimization opportunity. However, I was talking about the ribbon itself, meaning the thing you click on to open the sidebar, which is written in React. We need to find out how memory hungry React is to render that specific thing. Since it's keeping a virtual DOM in memory, I'm guessing it could be quite a bit compared to vanilla JS. However, whether React would be using 1MB, 5MB or 20MB on every page just to show the ribbon is something I have no idea about for the moment, which is what we need to investigate.

First, and easier thing to check out is whether the 25MB increase for every page is in the content script, or background script. If it does not get freed even if the page is closed, it's likely to be in the background page.