5 ms·

Sublime Text is one those modern tools that I would call snappy. I pray that it stays that way. I tried Atom once, but every key press had tiny lag, drove me in

Sublime Text is one those modern tools that I would call snappy. I pray that it stays that way. I tried Atom once, but every key press had tiny lag, drove me insane.

ben-schaaf 6y ago
I can say with confidence that Sublime products will always have a focus on performance. We generally treat any performance issues as high priority and you can see the result of that with most updates shipping some kind of speedup. Sublime Merge 2 for instance has shipped GPU rendering which has seen massive improvements at huge resolutions like 8k. Disclaimer: I work for Sublime HQ.
- badhombres 6y ago
  1. I can say I really appreciate the fact that you guys focus so much on performance. 2. I understand that sublime is closed source and respect that, but would sublime ever release or talk about how they develop their GUI? What libraries and techniques they use?
  - ben-schaaf 6y ago
    There's a fair amount of information scattered around about how parts of our GUI toolkit work, but there may be a blog post or two about that in the future. In general though it's not a particularly novel design on the toolkit end - the basics are all pretty similar to others. We just tend to put a lot of effort into making things work well and work fast.
- OnlyOneCannolo 6y ago
  I've read that Sublime uses its own custom GUI toolkit. If you had to write Sublime from scratch today, do you think you'd go the same route?
  - ben-schaaf 6y ago
    I wasn't there when that decision was made, so it's hard to say, but there's good reasons we tend to re-implement stuff found in existing open source software: Designing and building our own lets us be faster for our specific use case and gives us the control to fix bugs that are performance related or otherwise. It also means we hold a full understanding of the stack in-house allowing us to fix a lot of things. The most painful bugs for us to fix usually come from things we don't have direct control over, like OpenGL drivers, system libraries, etc. As a hypothetical example if we used GTK instead and it's rendering implementation was designed to be CPU based - say it's based on direct pixel manipulation by passing around a texture - if we wanted to be performant at high resolutions we'd have to refactor/rewrite large parts of GTK to use GPU rendering instead. That would mean either working with the maintainers to get something they'd be happy merging, then doing the work for all of gtk, or forking gtk ripping out the parts we don't use and just refactoring those. The latter would be significantly less work and the likely choice, so we'd likely end up in the same place as before.
    - muststopmyths 6y ago
      May I ask how well you compare with Visual Studio + Visual Assist for Unreal Engine 4 projects on Windows ? This is not just a performance question. I've gotten beyond tired of the thousands of paper cuts with the current combo and would love to find a better solution on Windows, even if it is paid. thanks. Edit: Just saw it's free to try. going to download it and try out
- darkhorse13 6y ago
  You guys are a gem. Probably the best piece of software I use.
- coldtea 6y ago
  What about a focus on a roadmap and more frequent updates? Sure, we've got Sublime Merge 2, but hardly anything for Sublime Text in almost a year (since last September I believe). And it's not like ST is done and perfect for eternity -- there are several issues still and lots of ways VSC has an edge for example...
signal11 6y ago
Pavel Fatin’s tests agree with you — search for “Editor latency in Windows (text file)” on this page: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ Interestingly gvim had the lowest latency in this test. I wonder if that’s a side effect of it being written largely in C (Sublime Text uses a proprietary cross-platform C++ framework).

Sublime Text is one those modern tools that I would call snappy. I pray that it stays that way. I tried Atom once, but every key press had tiny lag, drove me insane.

ben-schaaf 6y ago

I can say with confidence that Sublime products will always have a focus on performance. We generally treat any performance issues as high priority and you can see the result of that with most updates shipping some kind of speedup. Sublime Merge 2 for instance has shipped GPU rendering which has seen massive improvements at huge resolutions like 8k. Disclaimer: I work for Sublime HQ.

badhombres 6y ago
1. I can say I really appreciate the fact that you guys focus so much on performance. 2. I understand that sublime is closed source and respect that, but would sublime ever release or talk about how they develop their GUI? What libraries and techniques they use?
- ben-schaaf 6y ago
  There's a fair amount of information scattered around about how parts of our GUI toolkit work, but there may be a blog post or two about that in the future. In general though it's not a particularly novel design on the toolkit end - the basics are all pretty similar to others. We just tend to put a lot of effort into making things work well and work fast.
OnlyOneCannolo 6y ago
I've read that Sublime uses its own custom GUI toolkit. If you had to write Sublime from scratch today, do you think you'd go the same route?
- ben-schaaf 6y ago
  I wasn't there when that decision was made, so it's hard to say, but there's good reasons we tend to re-implement stuff found in existing open source software: Designing and building our own lets us be faster for our specific use case and gives us the control to fix bugs that are performance related or otherwise. It also means we hold a full understanding of the stack in-house allowing us to fix a lot of things. The most painful bugs for us to fix usually come from things we don't have direct control over, like OpenGL drivers, system libraries, etc. As a hypothetical example if we used GTK instead and it's rendering implementation was designed to be CPU based - say it's based on direct pixel manipulation by passing around a texture - if we wanted to be performant at high resolutions we'd have to refactor/rewrite large parts of GTK to use GPU rendering instead. That would mean either working with the maintainers to get something they'd be happy merging, then doing the work for all of gtk, or forking gtk ripping out the parts we don't use and just refactoring those. The latter would be significantly less work and the likely choice, so we'd likely end up in the same place as before.
  - muststopmyths 6y ago
    May I ask how well you compare with Visual Studio + Visual Assist for Unreal Engine 4 projects on Windows ? This is not just a performance question. I've gotten beyond tired of the thousands of paper cuts with the current combo and would love to find a better solution on Windows, even if it is paid. thanks. Edit: Just saw it's free to try. going to download it and try out
darkhorse13 6y ago
You guys are a gem. Probably the best piece of software I use.
coldtea 6y ago
What about a focus on a roadmap and more frequent updates? Sure, we've got Sublime Merge 2, but hardly anything for Sublime Text in almost a year (since last September I believe). And it's not like ST is done and perfect for eternity -- there are several issues still and lots of ways VSC has an edge for example...

signal11 6y ago

Pavel Fatin’s tests agree with you — search for “Editor latency in Windows (text file)” on this page: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ Interestingly gvim had the lowest latency in this test. I wonder if that’s a side effect of it being written largely in C (Sublime Text uses a proprietary cross-platform C++ framework).