Memory usage with large list


I recently watched a video call " Run Photoshop FAST with 1000+ Layers! Easy Trick" on YouTube. I don’t know anything about programming, but it might give you guys some ideas how you can improve the performance with large file (he was able to decrease memory usage from 37.8GB to 77.2MB by technically only display 2 layers). I don’t know it will help or not, but if not at least you learn a new trick for Photoshop. LOL. Happy New Year!


I’m surprised and, honestly, concerned that the only 2 options being considered are “don’t store all the data in memory” or “ignore the memory usage problem”. I’m sure there’s room to optimize how the data is stored / handled in memory, based on my observations:
I imported my WorkFlowy outline and split it into 2 documents. When viewing the larger of the two, Dynalist uses 800MB of memory. The OPML export of my outline from WorkFlowy is 2.4MB. The export from Dynalist of the same outline is 3.5 MB uncompressed in OPML and 1.9 MB in text. Even with 2x or 3x encoding overhead, the outline data itself does not come close to accounting for 800MB of memory usage.

My WorkFlowy tab is currently using 345 MB, while retaining the ability to search the entire outline and navigate quickly. WorkFlowy did recently release a rewrite that made it so snappy, but even before that, it was still faster and used less memory than Dynalist.

Even though I prefer WorkFlowy’s “everything is one outline” approach (because it’s less mental overhead for me), I did attempt to convert to the Dynalist way of multiple documents to try to mitigate the performance issues. Unfortunately, this caused the items I moved to lose their date metadata, which was the last straw that sent me back to WorkFlowy for now.

I do hope you guys are able to solve this issue, because WorkFlowy could use some competition in terms of features.


@dan_smith_X1011 @Erica @Shida I did some quick experimentation. It seems to me that memory usage is much higher when I have documents opened with a lot of images in it, i.e. the high memory usage is for most parts not from having all the text indexed (because that doesn’t change with changing the document) but rather that all images are loaded even if the respective item is not openened / visible on screen.

Also see App consumes 160 MB of data with little usage


It might be the images if he’s coming from WorkFlowy… WorkFlowy doesn’t support image markdown if I remember correctly.

@dan_smith_X1011: I think the 2-3x encoding overhead is reasonable, but the DOM elements and internal structures (parse tree for markdown, internal tag index, etc) do take a lot of space. If the 2-3x encoding overhead is the majority, the 345 MB memory used by WorkFlowy would be crazy as well (more than 100x of the OPML size).