4 ms·

For this sort of thing, with a fixed amount of developer time: - Performance - Stability - Actually working you can pick 2. Also, if you pick performa

by rtpg 12y ago

For this sort of thing, with a fixed amount of developer time: - Performance - Stability - Actually working you can pick 2. Also, if you pick performace, 50% of the time you can only pick 1. Everything is a tradeoff but it's a lot easier to sell something slow than to sell something that doesn't work, and a lot of the performance costs are due to general techniques encoded in these frameworks that reduce bugs. Another thing is that things do get faster. I think V8 has gotten 10x faster (at least) on real code since its inception. And that's despite JS not having changed.

forrestthewoods 12y ago
Sublime Text is all three.
- couchand 12y ago
  vim has been all three for twenty years.
  - tinco 12y ago
    Vim is not performant. Try scrolling in Vim, then try scrolling in Sublime.
    - mackwic 12y ago
      Seems fine on my >500Go aggregated log file. Scroll line by line with no issues. Sed and matching is near instant. What's the issue ?
      - tinco 12y ago
        I'm not sure why you would open a log file with vim, but that's besides the issue. The issue is with 500 line files. Open one up in Sublime and one in Vim. If you only use Vim you'll never discover what it to means to have a performant editor (I've used Vim for ~10yrs and still regularly do).
        elektronjunge 12y ago
        I have no idea what you are talking about. I opened a 26,000 line file (no I don't want to talk about it). In vim it opened instantly and my scrolling was only limited by my key repeat rate. The scrolling isn't as smooth looking because vim doesn't animate the scrolling between lines. Sublime took 2 seconds to open the same file, and scrolling was smooth. Maybe you are using to many vim plugins? I'll admit vim plugins are a real problem, the gui rendering desperately needs to be moved to its own thread.
        devonkim 12y ago
        I think there may be a possibility of the terminal itself being slow. Years ago when I used semi transparent terminals in something like enlightenment it was seriously noticeable when you were trying to scroll through text and it'd take a while to appear. Then I switched to using a simple terminal like rxvt and no transparency effects under ion2 and wow was it fast. So, perhaps the answer is that it's not the editor nor plugins that's slow in the scenario. I think the line numbering even causes some slight slowdown. Anything that actually parses text will obviously cause a performance hit too. I notice slowdowns when I use visual selection modes combined with tricky combos of commands. Even without any of that, it might be possible that the version of vim is doing something stupid like what happens when you open up a 1GB log file in less and hit G. Haven't run an strafe to understand the fseek calls being made but that's been painful without exception in my experience. Perhaps that's what the poster was recalling.
    - moron4hire 12y ago
      Vim itself is fine, but the plethora of plugins that a lot of people install can drag it down. Firefox has the same problem with extensions. And it's really not the fault of the base package. It's the plugin developers not doing due diligence, and it's the shear number of plugins making it impossible to test all combinations.
    - nine_k 12y ago
      Vim can be blazingly fast and maddeningly slow — it all depends on the plugins you have activated.
    - mmgutz 12y ago
      i tried but sublime doesn't work in SSH :( You're right. Editing a large file with syntax coloring and vim slows to a crawl. I just can't get away from Vim though as it works so well in terminals.
      - aktau 12y ago
        This is mostly to do with the syntax matching, the regexes used for that, and thus ultimately also the implementation of the regex engine (which was more or less swapped in Vim 7.4). It bother me a bit too (but not too much). Perhaps it can be mended, we'll see :).
- bdcravens 12y ago
  I love ST; I happily bought a v2 license a while ago, and will buy v3 when it's an option. I just get nervous about the resources being allocated to its development, so I've run Atom almost exclusively for a few months as a hedge.
  - chipotle_coyote 12y ago
    It's worth noting that if you haven't checked in recently, ST3 development appears to be back on track and proceeding at a pretty good clip. (Having said that, I'm keeping my eye on Atom myself. My big concern with ST3 is that the combination of closed source and single developer gives it a bus factor of 1. I'm hoping Jon follows through on his vague plan to get another developer in this year.)
    - bdcravens 12y ago
      Yeah, that's what I mean by resource allocation. I've downloaded the latest builds, but in my gut it doesn't feel like it's enough.
TimJRobinson 12y ago
Cloud9 manages to pull off all 3, and in javascript to boot. I honestly don't notice any difference in performance between it and ST3 (other than initial loading, which is a given seeing as it's web based).
freshhawk 12y ago
That is definitely not one those "pick two" situations. The relationship between those 3 things is quite different, in fact having one normally implies a better than average chance of having the others. You can not release a feature until it is performant, stable and working. You just won't release a lot of features. If you have the testing and release procedures that keep things stable and working - testing for performance regressions is easier, not harder. The classic "pick 2" situations is time, cost, features. Picking any one of those makes the other two harder to do, not easier.

by rtpg 12y ago

forrestthewoods 12y ago

Sublime Text is all three.

couchand 12y ago
vim has been all three for twenty years.
- tinco 12y ago
  Vim is not performant. Try scrolling in Vim, then try scrolling in Sublime.
  - mackwic 12y ago
    Seems fine on my >500Go aggregated log file. Scroll line by line with no issues. Sed and matching is near instant. What's the issue ?
    - tinco 12y ago
      I'm not sure why you would open a log file with vim, but that's besides the issue. The issue is with 500 line files. Open one up in Sublime and one in Vim. If you only use Vim you'll never discover what it to means to have a performant editor (I've used Vim for ~10yrs and still regularly do).
      - elektronjunge 12y ago
        I have no idea what you are talking about. I opened a 26,000 line file (no I don't want to talk about it). In vim it opened instantly and my scrolling was only limited by my key repeat rate. The scrolling isn't as smooth looking because vim doesn't animate the scrolling between lines. Sublime took 2 seconds to open the same file, and scrolling was smooth. Maybe you are using to many vim plugins? I'll admit vim plugins are a real problem, the gui rendering desperately needs to be moved to its own thread.
        devonkim 12y ago
        I think there may be a possibility of the terminal itself being slow. Years ago when I used semi transparent terminals in something like enlightenment it was seriously noticeable when you were trying to scroll through text and it'd take a while to appear. Then I switched to using a simple terminal like rxvt and no transparency effects under ion2 and wow was it fast. So, perhaps the answer is that it's not the editor nor plugins that's slow in the scenario. I think the line numbering even causes some slight slowdown. Anything that actually parses text will obviously cause a performance hit too. I notice slowdowns when I use visual selection modes combined with tricky combos of commands. Even without any of that, it might be possible that the version of vim is doing something stupid like what happens when you open up a 1GB log file in less and hit G. Haven't run an strafe to understand the fseek calls being made but that's been painful without exception in my experience. Perhaps that's what the poster was recalling.
  - moron4hire 12y ago
    Vim itself is fine, but the plethora of plugins that a lot of people install can drag it down. Firefox has the same problem with extensions. And it's really not the fault of the base package. It's the plugin developers not doing due diligence, and it's the shear number of plugins making it impossible to test all combinations.
  - nine_k 12y ago
    Vim can be blazingly fast and maddeningly slow — it all depends on the plugins you have activated.
  - mmgutz 12y ago
    i tried but sublime doesn't work in SSH :( You're right. Editing a large file with syntax coloring and vim slows to a crawl. I just can't get away from Vim though as it works so well in terminals.
    - aktau 12y ago
      This is mostly to do with the syntax matching, the regexes used for that, and thus ultimately also the implementation of the regex engine (which was more or less swapped in Vim 7.4). It bother me a bit too (but not too much). Perhaps it can be mended, we'll see :).
bdcravens 12y ago
I love ST; I happily bought a v2 license a while ago, and will buy v3 when it's an option. I just get nervous about the resources being allocated to its development, so I've run Atom almost exclusively for a few months as a hedge.
- chipotle_coyote 12y ago
  It's worth noting that if you haven't checked in recently, ST3 development appears to be back on track and proceeding at a pretty good clip. (Having said that, I'm keeping my eye on Atom myself. My big concern with ST3 is that the combination of closed source and single developer gives it a bus factor of 1. I'm hoping Jon follows through on his vague plan to get another developer in this year.)
  - bdcravens 12y ago
    Yeah, that's what I mean by resource allocation. I've downloaded the latest builds, but in my gut it doesn't feel like it's enough.

TimJRobinson 12y ago

Cloud9 manages to pull off all 3, and in javascript to boot. I honestly don't notice any difference in performance between it and ST3 (other than initial loading, which is a given seeing as it's web based).

freshhawk 12y ago

That is definitely not one those "pick two" situations. The relationship between those 3 things is quite different, in fact having one normally implies a better than average chance of having the others. You can not release a feature until it is performant, stable and working. You just won't release a lot of features. If you have the testing and release procedures that keep things stable and working - testing for performance regressions is easier, not harder. The classic "pick 2" situations is time, cost, features. Picking any one of those makes the other two harder to do, not easier.