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.
4 Likes
@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.
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).
I want to add a quick âme too.â I imported my workflowy list and dynalist chugged, even navigating the non-list portions of the UI was a crawl. It got better when I closed the open lists, but workflowy is fast even with everything open.
I too would like software with more features such as dynalist, but speed is everything.
âMove at the speed of thoughtâ