5 ms·

> replacement for visual studio but faster How can a IntelliJ Idea derivative written in Java be faster than VistalStudio which is native code? Both Idea and P

> replacement for visual studio but faster How can a IntelliJ Idea derivative written in Java be faster than VistalStudio which is native code? Both Idea and PyCharm work much slower than VisualStudio on my machine.

eberkund 7y ago
Because VS has limitations on the amount of memory it can use and although they have been working on this, there is still functionality which is highly single threaded whereas Rider tends to offload most of the functionality from the UI thread into background processes.
- eyegor 7y ago
  The memory limitations can be partially kicked down the road by setting /largeaddressaware on devenv.exe. Ofc it's still beyond frustrating when you have a large solution with many component projects. I personally ram against the 4gb ceiling constantly.
- qwerty456127 7y ago
  I see, this means Rider is faster than the VS on many-core machines with huge amounts of memory. That's why it isn't going to be fast for me - I only use laptops, with 4 GiB RAM and dual cores each.
fuzzy2 7y ago
Visual Studio isn't native though. It's .NET and COM. That's also why we're still stuck with 32-bit VS.
- int_19h 7y ago
  COM is an ABI, and is often implemented in native code, C++ usually. There's still plenty of C++ inside VS.
- hermitdev 7y ago
  That's not why VS is still 32-bit. Apparently folks at MS dont think the extra address space isnt worth it and think it would adversely affect performance [1]. In my own experience in migrating servers from 32 to 64-bit on Linux 12 years ago, 64-bit was around 10-20% slower than the 32-bit build. Dont how itd fare today (no longer at that job). Even though performance was demonstrably slower, 64-bit it was due to edict from the CEO. For what its worth, neither of the services I was responsible benefited from the extra address space. Mem usage for bother services peaked at around 750 MB. [1] https://docs.microsoft.com/en-us/archive/blogs/ricom/revisiting-64-bit-ness-in-visual-studio-and-elsewhere https://docs.microsoft.com/en-us/archive/blogs/ricom/revisit...
  - ygra 7y ago
    Rico has a point to a degree and every VS version since then reduced memory footprint and improved performance (mostly due to not calculating stuff up-front which may never be needed and doing it on demand). Microsoft has also pushed since VS 2008 (!) for plug-ins and extensions to use an out-of-process model. I think ReSharper got the message in summer 2019 that it might be a good idea – and incidentally, a lot of their performance comparison of Rider vs. VS comes down to "Rider uses ReSharper in another process, so the IDE doesn't slow down when ReSharper does things", while they themselves still pursued the slower model in VS. Heck, until a few releases ago ReSharper was still using the old synchronous COM APIs for querying the solution after loading, leading to severe pauses when opening a solution or re-loading it after switching source control states. Vanilla VS is plenty fast and not that memory-hungry. In my experience it's extensions that try to sync with IDE state where a lot of the waiting comes in and in-process extensions where a lot of the memory usage comes from.
    - pjmlp 7y ago
      Out of process model is actually much better idea, given the instability and possible exploits of in-proces plugins. I also never liked ReSharper, the performance drop versus vanilla VS isn't worth it.
GordonS 7y ago
At least for me, Rider is definitely faster than Visual Studio, both in startup time (easily human-measurable) and operation (also easily human measurable, by lack of intermittent hangups and laptop fans constantly whining). I'd also say that Rider is more stable - I've only ever seen issues with preview versions; the production versions are solid, which can't be said for Visual Studio. I was a Visual Studio fanboi for many years before discovering Rider, so wouldn't be easily swayed - please, try it and see for yourself!
Ididntdothis 7y ago
Visual Studio is written in WPF which is not exactly a speed demon.
- pjmlp 7y ago
  Still way faster than Swing.
jen20 7y ago
Visual Studio has been unable to keep up with my (not notably fast) typing since like 2005. Rider has no issue. Nor does IntelliJ or CLion or Goland.
- michalstanko 7y ago
  I worked in Visual Studio full-time for many years, now I'm coding in PhpStorm (IntelliJ IDEA) since July 2019, and while overall it's really powerful, I still kind of miss VS. One notable problem I have with PhpStorm is that oftentimes when I'm trying to find files or text in files, I press the respective keyboard shortcut and start typing immediately, in WebStorm the first few letters often end up being typed into the currently opened file instead of the "Find..." dialog, which never happened to me in VS. A minor issue, but it occurs every single day. A similar thing makes me go nuts in Windows as well - in Windows 7 I pressed the WinKey and started typing immediately to find an application, never had a problem, but Windows 10 often misses the first few keystrokes after the Start menu opens. I can't believe this hasn't been fixed for years. -- EDIT: fixed a typo
  - throwaway8941 7y ago
    Windows 10 start menu is so bad I cut it out from every Windows machine I have any authority over. Try Keypirinha, it's very snappy and supports fuzzy search. https://keypirinha.com/ https://keypirinha.com/
    - qwerty456127 7y ago
      Why is it bad? It lists installed apps alphabetically, almost the same way all the previous Windows versions did and it has a search field to find an app quickly (AFAIK it can also search through other things but I always disable indexing and integrated web search functionality). How often do you even have to use it? I've just pinned everything I use regularly to the task bar and only use the start menu on rare occasions.
LandR 7y ago
Rider is miles faster than visual studio for me!
- qwerty456127 7y ago
  That probably is because you have more than 4 GiBs of RAM and/or more than 2 CPU cores.
yread 7y ago
I haven't used rider but VS can spin up some Nodejs processes if you work with js and they are an abomination
emodendroket 7y ago
A faster algorithm matters more than the choice of programming language, as algorithm textbook authors love to remind you.

eberkund 7y ago

Because VS has limitations on the amount of memory it can use and although they have been working on this, there is still functionality which is highly single threaded whereas Rider tends to offload most of the functionality from the UI thread into background processes.

eyegor 7y ago
The memory limitations can be partially kicked down the road by setting /largeaddressaware on devenv.exe. Ofc it's still beyond frustrating when you have a large solution with many component projects. I personally ram against the 4gb ceiling constantly.
qwerty456127 7y ago
I see, this means Rider is faster than the VS on many-core machines with huge amounts of memory. That's why it isn't going to be fast for me - I only use laptops, with 4 GiB RAM and dual cores each.

fuzzy2 7y ago

Visual Studio isn't native though. It's .NET and COM. That's also why we're still stuck with 32-bit VS.

int_19h 7y ago
COM is an ABI, and is often implemented in native code, C++ usually. There's still plenty of C++ inside VS.
hermitdev 7y ago
That's not why VS is still 32-bit. Apparently folks at MS dont think the extra address space isnt worth it and think it would adversely affect performance [1]. In my own experience in migrating servers from 32 to 64-bit on Linux 12 years ago, 64-bit was around 10-20% slower than the 32-bit build. Dont how itd fare today (no longer at that job). Even though performance was demonstrably slower, 64-bit it was due to edict from the CEO. For what its worth, neither of the services I was responsible benefited from the extra address space. Mem usage for bother services peaked at around 750 MB. [1] https://docs.microsoft.com/en-us/archive/blogs/ricom/revisiting-64-bit-ness-in-visual-studio-and-elsewhere https://docs.microsoft.com/en-us/archive/blogs/ricom/revisit...
- ygra 7y ago
  Rico has a point to a degree and every VS version since then reduced memory footprint and improved performance (mostly due to not calculating stuff up-front which may never be needed and doing it on demand). Microsoft has also pushed since VS 2008 (!) for plug-ins and extensions to use an out-of-process model. I think ReSharper got the message in summer 2019 that it might be a good idea – and incidentally, a lot of their performance comparison of Rider vs. VS comes down to "Rider uses ReSharper in another process, so the IDE doesn't slow down when ReSharper does things", while they themselves still pursued the slower model in VS. Heck, until a few releases ago ReSharper was still using the old synchronous COM APIs for querying the solution after loading, leading to severe pauses when opening a solution or re-loading it after switching source control states. Vanilla VS is plenty fast and not that memory-hungry. In my experience it's extensions that try to sync with IDE state where a lot of the waiting comes in and in-process extensions where a lot of the memory usage comes from.
  - pjmlp 7y ago
    Out of process model is actually much better idea, given the instability and possible exploits of in-proces plugins. I also never liked ReSharper, the performance drop versus vanilla VS isn't worth it.

GordonS 7y ago

At least for me, Rider is definitely faster than Visual Studio, both in startup time (easily human-measurable) and operation (also easily human measurable, by lack of intermittent hangups and laptop fans constantly whining). I'd also say that Rider is more stable - I've only ever seen issues with preview versions; the production versions are solid, which can't be said for Visual Studio. I was a Visual Studio fanboi for many years before discovering Rider, so wouldn't be easily swayed - please, try it and see for yourself!

Ididntdothis 7y ago

Visual Studio is written in WPF which is not exactly a speed demon.

pjmlp 7y ago
Still way faster than Swing.

jen20 7y ago

Visual Studio has been unable to keep up with my (not notably fast) typing since like 2005. Rider has no issue. Nor does IntelliJ or CLion or Goland.

michalstanko 7y ago
I worked in Visual Studio full-time for many years, now I'm coding in PhpStorm (IntelliJ IDEA) since July 2019, and while overall it's really powerful, I still kind of miss VS. One notable problem I have with PhpStorm is that oftentimes when I'm trying to find files or text in files, I press the respective keyboard shortcut and start typing immediately, in WebStorm the first few letters often end up being typed into the currently opened file instead of the "Find..." dialog, which never happened to me in VS. A minor issue, but it occurs every single day. A similar thing makes me go nuts in Windows as well - in Windows 7 I pressed the WinKey and started typing immediately to find an application, never had a problem, but Windows 10 often misses the first few keystrokes after the Start menu opens. I can't believe this hasn't been fixed for years. -- EDIT: fixed a typo
- throwaway8941 7y ago
  Windows 10 start menu is so bad I cut it out from every Windows machine I have any authority over. Try Keypirinha, it's very snappy and supports fuzzy search. https://keypirinha.com/ https://keypirinha.com/
  - qwerty456127 7y ago
    Why is it bad? It lists installed apps alphabetically, almost the same way all the previous Windows versions did and it has a search field to find an app quickly (AFAIK it can also search through other things but I always disable indexing and integrated web search functionality). How often do you even have to use it? I've just pinned everything I use regularly to the task bar and only use the start menu on rare occasions.

LandR 7y ago

Rider is miles faster than visual studio for me!

qwerty456127 7y ago
That probably is because you have more than 4 GiBs of RAM and/or more than 2 CPU cores.

yread 7y ago

I haven't used rider but VS can spin up some Nodejs processes if you work with js and they are an abomination

emodendroket 7y ago

A faster algorithm matters more than the choice of programming language, as algorithm textbook authors love to remind you.