+22
Started

Very high memory usage in TO

Mayank Mehrotra 6 years ago • updated by Terrence Brannon 2 months ago 16
For some reason when Chrome first opens, TO is using somewhere around 250 MBs of memory. Is there a reason for this or does this have to do with the number of saved webpages (I do have a lot of saved pages, due to duplicates from crashing Chrome and restoring the pages through the "Restore" button)...?


Answer

+4
Answer
Started

From version to version there is a progress in this regards actually. Next version will have even lower memory usage. But some limits just very hard to overcome. Take note that sometimes even the simplest web pages consume dozen of megabytes of ram in the Chrome. It is well famous for this feature : )


The 250 MB memory consumption can be real. If you have something around 15 000 saved nodes. Next version will reduce this, but not on a magnitude.


My advice for now, if you have many thousands nodes (note that other extension just cannot even come close to such counts of simultaneously visible nodes) and the ram consumption is a big issue for you - expand all nodes, save the tree as a plain text web page (through Ctrl-S). 

Check if this page is rendered ok (reopen it in some tab)


Then uninstall Tabs Outliner - this will delete all its data (WARNING!!! THIS WILL DELETE ALL ITS DATA!!! RE READ THIS). Then install it again and start your tree from scratch. This will return you ram usage to 10-15MB. 

Use your saved in html tree to access  for old data (you can drag from it back to main view some individual windows and groups by the way). 

Other solution - having most of the part of tree collapsed - if items is collapsed it is not rendered in HTML, and consume very little ram. But it is actually more useful to have your old tree as a separate web page.


There is some price that need to be paid for some features. If you have a lot of data visible on screen in HTML world this is unfortunately lead to a big memory usage. In fact - if you continue to grow your tree indefinitely the ram usage will continue to grows also, you can reach any digits that you want this way. So you need decide what is more important for you - the ram, or having all the data in one tree.


I am periodically (once in 6 months actually) drop the whole tree in a file and start from scratch. Soon there will be better way for a same - it will be possible to create separate tree documents. So all the data will continue to be searchable and editable (the tree in a static HTML file is not editable by drag and drop... but editable in any HTML editor by the way)


Best.


+1

How many saved nodes do you have in your tree?

(this can be measured by collapsing the root node temporary)


+4
Answer
Started

From version to version there is a progress in this regards actually. Next version will have even lower memory usage. But some limits just very hard to overcome. Take note that sometimes even the simplest web pages consume dozen of megabytes of ram in the Chrome. It is well famous for this feature : )


The 250 MB memory consumption can be real. If you have something around 15 000 saved nodes. Next version will reduce this, but not on a magnitude.


My advice for now, if you have many thousands nodes (note that other extension just cannot even come close to such counts of simultaneously visible nodes) and the ram consumption is a big issue for you - expand all nodes, save the tree as a plain text web page (through Ctrl-S). 

Check if this page is rendered ok (reopen it in some tab)


Then uninstall Tabs Outliner - this will delete all its data (WARNING!!! THIS WILL DELETE ALL ITS DATA!!! RE READ THIS). Then install it again and start your tree from scratch. This will return you ram usage to 10-15MB. 

Use your saved in html tree to access  for old data (you can drag from it back to main view some individual windows and groups by the way). 

Other solution - having most of the part of tree collapsed - if items is collapsed it is not rendered in HTML, and consume very little ram. But it is actually more useful to have your old tree as a separate web page.


There is some price that need to be paid for some features. If you have a lot of data visible on screen in HTML world this is unfortunately lead to a big memory usage. In fact - if you continue to grow your tree indefinitely the ram usage will continue to grows also, you can reach any digits that you want this way. So you need decide what is more important for you - the ram, or having all the data in one tree.


I am periodically (once in 6 months actually) drop the whole tree in a file and start from scratch. Soon there will be better way for a same - it will be possible to create separate tree documents. So all the data will continue to be searchable and editable (the tree in a static HTML file is not editable by drag and drop... but editable in any HTML editor by the way)


Best.


To add to this my 1700 node tree opens at only ~30mb usage, but begins to balloon outward, typically hovering semi-stably at ~450mb by the 48 hour mark. More problematic for me is the fact none of that memory gets released even with no tabs outliner window open, chrome has to be closed entirely to free it.

+1

This is really a serious issue, it's appears after one of the recent Chrome releases. Some memory leaks was present before, but after the latest Chrome updates they go completely out of control. Same problem for me. Working now on this.


Meantime the only advice - from time to time to go in chrome://extensions/ and disable and then again enable the TO - this will release all the memory leaks.

Maybe i will add automatic auto-reset. Which will do the same if all TO windows is closed - as quick solution

+1

Some other extensions that i use seems also start behave in this way. Looks like we have some serious changes inside Chrome regarding how JS memory is released.


Can i ask how much physical RAM do you have?

Looks like this "semi-stably" bound is depend on this. 

+1

8 gigs. And that proportional bounding is very interesting info.

+1

Thanks for information.

Looks like this is really depends on available ram.


Anyway, in a day or 2 i will release a version which will automatically reload self after any TO view close, and on every hour. It is also will have some other performance improvements.


Hope this solve issue for some time. Also I really plan to do something about this memory usage - i am mostly have the TO View always visible. So reload is not a ideal solution. Have some ideas what can be done. But this will require more time. 

@vladyslav

I'm not familiar with the implementation but I'm not sure why would re-installing TO and then dragging the very same tree you had before into it, affect the RAM usage? What kind of info do you keep in the data files that would lead to accumulating RAM usage over time? I would think it's only a link and a session state (like, i don't know, tab history?). If the session state preservation is to blame, then the workaround you suggest is not really optimal, as it probably destroys the associated sessions?
+1
Please read carefully my comment - it has the warning in all CAPS,  i am not talking in it about reinstalling. But about just disabling/enabling. Do not uninstall - this will really delete everything.

I make some changes recently, the memory usage goes down a bit.
Yet the problem is still be real.
I feel that the complete fix is possible and i plan to investigate this problem and completely fix in a few months. Most likely this will require to implement some sort of pagination, and a brand new search. A big task.... but very needed and it's planed.


+1
I use The Great Suspender to reduce the number of tabs actually in memory.
+3
The problem is about TO memory usage.
On a 40 000 nodes for example TO really start to use a lot of RAM. There is already a fix for this. Plan to release it soon. RAM consumption will drop on a magnitude after this. Through It's all not relevant to users with only several thousand nodes.

As for Great Suspender - there is plans to integrate it more closely with TO. At least display the state of suspended by Great Suspender tabs and on restore restore saved items that was suspended before save, as not suspended. Is this sound good? I myself do not use Great Suspender but it's looks like this simple steps will make it more useful companion with TO - so any comments will be interesting to hear.

+1
Just to add some data to this:

Today I noticed high RAM usage.  I had 1176 nodes and saw Tabs Outliner is using 767 Megs of RAM.  I un-enabled and then re-enabled the extension and re-opened the TO window, and now I see 44 Megs of RAM used.  My system has 16 gigs.

I rarely restart Chrome, but lately I've been restarting TO about once a week due to this.
+1
Yes, not something to be proud of.
This is actually not the Tabs Outliner data but more like Java Script virtual machine garbage, that is actually garbage collected by Chrome when they need more ram. Through i myself regularly restart TO because of this issue. For 50 000 nodes the number is same actually. 
Version with much better memory usage planned to be released in 2 months.
+1

there must be a more simplistic way to do this using the cloud features of the pro version. I manage multiple computers with tab outliner and I bet there could be a feature that allows you to merge documents into one save tree.

+1

Any update on a fix for this?  the memory leaking is severely affecting the usability of this tool.  I have an older machine here so I can't easily upgrade (MacbookPro3,1 (w/ 6GB of DDR2 RAM + Samsung SSD) + OSX 10.6.8 + Chrome 49 + ScriptBlock 1.5 + ABP 3.5 + TO 1.4.134 + 5 windows (4 with 4~5 tabs, 1 with 20 tabs)) and within a few mins of browsing, the memory usage of just the TO process goes from 160MB to ~400MB, this is *without the TO window even being open*.  After an hour of *doing nothing* (ie: not browsing) the memory usage balloons to ~900MB ~1.5GB!!  I have to constantly disable/enable this extension to prevent this from sucking up all RAM and causing the system to go down.  I can literally watch the memory usage shoot up linearly via the graph in iStat Menus.  

I really think this is a great extension and rely on it heavily but am disappointed that memory management is a bit lacking.  Do you dealloc() memory for unused objects you create? or have you tried looking into troubleshooting/profiling memory issues for extensions running in Chrome's v8 JS engine?  Perhaps "lazy-loading" would help?  Just throwing out suggestions.... 

Have a lot of other great ideas on how to potentially improve the browsing experience via TO too, ie:  making the UI easier to organize / navigate / switch tabs, but I'll hold off on that for now... 

Thanks for creating this!

I'm finding Workona to be a bit more task-oriented. Some combination of the two would be sheer nirvana.