Sublime Forum

Sublime-workspace file contains irrelevant content, might slow down saving

#1

Before I file a bug report on GitHub, and go through the hassle of figuring out steps to reproduce, I’d like to learn whether I can just adjust my preferences to improve performance.

Context: I am using Sublime with two or three windows simultaneously, lately; each in a different project or workspace.

This current workspace only has 11 files open. The longest one of those only has 700k lines; a JavaScript file. That’s not much.

The other two workspaces have more files open, and some of them are really long. Some are … let’s say 6k lines on average. — That’s on me. I get it.

Problem: Saving or closing a file freezes Sublime for an actual second. Seems like some process is going through a large list of files or something. In my view, the other workspaces shouldn’t affect the current one like that.

I’ve had a look at the sublime-workspace files. One, for example, is 18k lines long. It contains lists that are (A) long(er than I need them to be) and (B) contain content that doesn’t belong to this workspace. (I’d say, this is the actual problem I would file a bug report for.)

This following list refers to relevant keys – how can I limit these lists individually?

  • select_symbol.selected_items (59 items — Not a single one applies to this workspace.)
  • select_file.selected_items (128 files — Again, most from another workspace. The [ File › Open Recent ] menu list isn’t even nearly that long: it only ever shows 12 items.)
  • file_history (128 items)
  • command_palette.selected_items (128 items — If these items are copied from worspace to workspace anyway, I suggest to store them project-independently, once, in ~/.config/ or something.)
  • buffers (only 7 items but starts on line 50 and ends on line 16429)

I didn’t have any crashes or file losses yet, but with freezes like that I feel like that’s only a question of time.

Build 4143
Ubuntu 18.04.6
Intel® Pentium® CPU N4200 @ 1.10GHz × 4
8GB RAM

0 Likes

#2

Okay, the undo buffer of a file is cleared when I close a file and reopen it.

But I didn’t know that it persists when I close the project and open it again. That doesn’t count as closing the file apparently.

That explains part of the slowdown, since I’ve kept some of those files in the other workspaces open for many months now.

I can help myself by closing the file and reopening it, I guess.

However, I still feel like the content relating to other workspaces shouldn’t bleed into the current one like that.

0 Likes

#3

It contains lists that are (A) long(er than I need them to be) and (B) contain content that doesn’t belong to this workspace . (I’d say, this is the actual problem I would file a bug report for.)

None of the keys you’ve listed don’t belong in the workspace. The file and symbol selection history is per-workspace as it should be. The file history needs to be stored both globally and per-workspace to support reopening closed files. The command palette is also clearly per-workspace. The reason these are pre-populated is because they are inherited from the previous window.

The undo history per text buffer is limited to 128kB so as not to grow indefinitely. Though if you have large unsaved files then those are kept in the session and may take up a lot of space. If you don’t want to keep files in the workspace you can use "hot_exit": "never", "hot_exit_projects": false, optionally with "remember_open_files": true if you still want to remember open files.

1 Like

#4

I’m sorry, a misunderstanding. I didn’t mean to say that select_symbol.selected_items (etc.) itself doesn’t belong in that file. It does / they do.

What I meant was that I’ve had workspace A with PHP files open and workspace B with stories that I’m writing. The symbols of the PHP files appear – but don’t belong, I claim – in the stories workspace.

I do have some unsaved files, but not that many. And I’ve noticed that they’re saved in full (makes sense). But they honestly don’t take up that much space. The undo buffer does.

The undo history per text buffer is limited to 128kB so as not to grow indefinitely.

I don’t know if the undo buffer is buggy or behaves as it’s supposed to be, then. How much is 128kB compared to …? How does it translate to …? Uhm, if I open the file and do [ CTRL+K, CTRL+3 ]-level code folding, the line number column tells me that some files in the buffers key are ~500 amount of lines long; some ~900; some ~2k. That’s how I “measure” them. Is this still 128kB?

I had one sublime-workspace file that was 3.4 MB big. Another one 5.4 MB. I managed to reduce them by going to the reference “big” files (big in terms of undo buffer) and actively close +reopen them. Then I closed the workspace. Now the 3.4 MB one is 170kB.

Personally, I don’t need (or expect) an undo buffer for a closed project. If I close Sublime and open it again, I don’t want CTRL+Z to do anything. I guess some people might though …?

Is there an option / preference / feature (planned) for the undo to behave that way?

0 Likes

#5

I don’t know if the undo buffer is buggy or behaves as it’s supposed to be, then. How much is 128kB compared to …? How does it translate to …?

The approximate amount of storage used in the session file.

Uhm, if I open the file and do [ CTRL+K, CTRL+3 ]-level code folding, the line number column tells me that some files in the buffers key are ~500 amount of lines long; some ~900; some ~2k. That’s how I “measure” them. Is this still 128kB?

Code folding isn’t persisted, so that has no bearing on the amount of undo history stored. Neither does the size of the file, though if the file is unsaved then it’ll have to be stored in the session. At 128kB with 30 files at the limit you can expect around ~4MB for the size of the session file.

I had one sublime-workspace file that was 3.4 MB big. Another one 5.4 MB.

Note that even a slow hard disk at 30MB/s should load/save those in under a second, especially on linux with its aggressive file caching. Depending on the number of files you have open that’s an expected size for the session file and should load/save quite quickly.

Does the smaller session file actually solve your issue with file saving/closing being slow? Can you still reproduce the issue in safe mode?

0 Likes

#6

The code folding does persist for me because of the AutoFoldCode package that I’ve installed.

The 5.4 MB file has ~12k lines alone in undo history buffer size – or 5 304 954 characters, or ~5.1 MB.

I didn’t have the time this week / today to test it in safe mode. Testing it would mean that I had to create ~3 MB worth of undo history after booting in safe mode, after all …

Doing the trick “close and reopen each file individually, then close and reopen project view” definitely does increase the performance on-save. The application saves faster and solves my issue. — It will just be annoying over time … for me to have to manually clear the undo buffer (full of uninteresting maybe-3-months-old actions) that way.

0 Likes

#7

I didn’t have the time this week / today to test it in safe mode. Testing it would mean that I had to create ~3 MB worth of undo history after booting in safe mode, after all …

You can load workspace files in safe mode.

My guess is plugins you’ve installed like AutoFoldCode are causing saving to be slow, not the session size.

0 Likes

#8

load workspace files in safe mode. — I now see what you’re saying.

AutofoldCode — That is entirely possible.

I will investigate these things when I find the time. Thanks for the advice.

0 Likes