[1261]Never ending story with VB Performance

At the beginning of a session the performance is acceptable, but the longer i work the slower the IDE reacts. I have to restart Visual Studio about every two hours to get  an acceptable performance. While editing VB source code the CPU load of Visual Studio is nearly permanent at 98%. Sometimes it takes 1 .. 2 Minutes until the enhanced syntax coloring appears. But more annoying is editing. Somtimes the intellisense pops up sometimes not. I move the cursor to the next line with the keyboard and nothing happens for 10 .. 20 seconds. When i use an class from a namespace i didn't imported sometimes the import namespace of Visual Studio is shown, sometimes the import namespace of R#. All in all no smooth editing is possible.

When i disable R# everything works well. Also when i work on C# projects i don't have any problems.It seems to me that the R# background processing causes conflicts or deadlocks with the background compile process of the VB IDE if you work on a large code base (the VB project i'm working on has around 200.000 lines of code). Im working with Visual Studio 2008 SP1 and Windows 7 C 64-Bit edition on a Dell Insprion laptop with a 2,7GHZ dual core CPU and 4 GB RAM.

If i can do anything to track the problem down more deeply please let me know.

Regards
Klaus

23 comments

Same here, i7 quadcore + 6gb on Vista64, and the VB performance is simply tragic even in 1621, cpu is at 100% all the time.
Not to mention r# intellisense extensions that are still not popping up automatically in VB (why?? i've read something about it being not possible, but that's just nonsense - all other coding assistance add-ins can do it).

Seems that VB is a second class citizen at JetBrains, but mind you, there is only certain amount of time you can ignore major bugs like these before your customers switch to competition, and at least for me, that time is nearing very very fast. Those (now very) few additional R# features are just not worth staring at non-responsive VS half a day.

0

Today i switched from my laptop to my desktop (which is much less performant, old Pentium D 3 GHZ with 3 GB RAM). On the desktop build 1241 is installed. In opposite to 1261 it rocks. I have noticed none of the performance issues of 1261. So i assume one of the changes / fixes caused the problem.

Again, i'm willing to help you to solve the problem. The performance of the current build would be a NO GO to relase 4.5.1 for me.

Regards
Klaus

0

Thanks for your reports!

Now I'm investigating build 1261 with large VB files. Unfortunately I haven't reproduced the problem yet. ;( Is it possible for you to capture profiler snapshot with this problem? It is the greatest thing you could do to help fixing this issue. I am ready to answer any questions concerning dotTrace profiler.

It's interesting remark about build 1241 - I'll try to investigate changes between these versions.

Regards,
Olga

0

Few questions:

*  Is it web project or simple VB project?
*  Is solution wide analyse switched ON? (green\red circle in the right-bottom corner)
*  Is option 'Highlight matching delimeters' switched ON? (resharper options -> editor -> braces and parentheses)
*  What ReSharper toolbars are shown?

0

Hi,

We don't have symbol completion in VB.net, only 'smart' and 'import symbol' completion. In our opinion this feature provided by Visual Studio for Visual Basic is quite good and enough. As far as I understand it is not so for you. Could you formulate what is missed in VS standart completion up to you, what features of ReSharper completion do you need?

Regards,
Olga

0

Olga Lobacheva wrote:

Few questions:

  • Is it web project or simple VB project?

it is a simple VB project which was migrated from VB6. Just one solution file with one project file

  • Is solution wide analyse switched ON? (green\red circle in the right-bottom corner)

Solution wide analysis is switched off

  • Is option 'Highlight matching delimeters' switched ON? (resharper options -> editor -> braces and parentheses)

in the editor options i have all switches on. "Highlight matching delimiters" is set to "at both sides" and "Outlining"
"Auto insert closing brace" is set to "on typing an opening brace".
By the way, Highlighting matching delimiters does not work with VB

  • What ReSharper toolbars are shown?

Didn't enable any tool bar

Today i installed the latest build on my Office desktop. The performance is not so good as with build 1241, but acceptable.
Renaming variables takes very long and when i move the caret in the editor with the cursor keys the cursor hangs very often for a
short while. The CPU load is permanently high (about 95-98%). As i leave my Notebook at home today i couldn't verify. if the
performance is better there with the new build, but i will check this at evening.

As the performance on the desktop is much better than on the notebook i have the idea that the problems may be caused either by
Windows 7 RC or by the fact, that i use the 64-bit version of Windows 7 on my notebook. I have installed Windows XP beneath Windows
7 so that i can test, if the operating system plays a role.

I gladly would profile my edit session with DotTrace, but i have installed a trial version sometimes ago and the trial key has
expired (and my boss is not willing to spend money for a profile tool :-(().

Regards
Klaus

0

By the way, Highlighting matching delimiters does not work with VB


here i was missing. Brace highlighting works, but it would be nice if highlighting will also work for for..next, if..end if and so on.

A first short test of build 1263 shows a better performance on my notebook, but in the last time the performance decreases over time.

Regards
Klaus

0

this morning i'm working extensive with "Find Usages". With the "Find usages" result window open the performance plunge down. On my notebook i have the ToDo explorer window opened (but collapsed). There are around 1000 todo comments (mostly warnings from the VB upgrade assistent in the code.

Regards
Klaus

0

Hello Klaus
     Could you please send an e-mail to andrew dot serebryansky at jetbrains dot com? I'll send you a dotTrace evaluation extension. Thank you!

Regards,
Andrew Serebryansky

0

Hello,

I've found few performance issues but all of them are not very important. I'll wait your profile snapshots, hope it will clear the problem.

P.S.: you can try to switch off 'Highlighting matching delimiters' cause it really stuck typing. And we can't fix it just now - may be in next release.

Regards,
Olga

0

i'm waiting for the key for extending my dotTrace trial. Can you give me some hints what i should profile?

Regards
Klaus

0

I create feature request for 'Highlight matching delimiters' functionality here: http://www.jetbrains.net/jira/browse/RSRP-113343

0

I was talking of course about Code and Symbol completion, which are not implemented at all.
Symbol and type name completion lists should be popping up automatically as in C#. If nothing else, VS intellisense doesn't do camel humps (major time saver), thus just isn't enough. If it was, why would you implement that for C# anyway.

Smart enter doesn't work in VB.

Parameter info doesn't pop up automatically as in C#.

Closing parenthesis are not inserted automatically.

Delimiter highlighting (if/end if, for/next etc.) would be nice to have.

And that's just couple of things off top of my head, I'm sure I would find more if I cared.

To that performance problem, 1243 works fine, too. I don't know about Klaus, but I am also using CR/RP at all times. Maybe you introduced some conflict with it in builds past 1243?

Also one more suggestion, it wouldn't hurt if you could switch between normal and smart completion with just one key, say Alt - so that when the Code completion window is shown you wouldn't have to press something as RSI inducing as ctrl+shift+space to get there.

0

Another thing which comes to my mind when i compare the c# with the vb features is the error indicator. VB stops compiling after a maximum of 100 errors occured. Another thing is, that the error list differs after each background compile (which occurs each time i leave a row in the editor). There are situations where the errors in the currently edited file disappears. It would be great if you can mark the errors in the status bar beneath the scrollbar like you do for c#.

It would be perfect if you can find a way to surpress the background compile process of VB. This process is a great performance break (even with R# disabled). I hoped MS would have an option to do this in VS2010 but it seems they won't do this.

Regards
Klaus

0

starting with build 1268 the performance began to be better. With build 1270 the performance is acceptable for me. I specially
noticed that the delay before the R# syntax highlighting works is much shorter. The intellisense popups are shown much faster,
moving around in the code with the cursor is much faster and the most important for me, the CPU load is no longer permanently high
(because the CPU-fan of my machine is quite loud ;)). Good work until now...

Regards
Klaus

0

Thanks a lot for your feedback. We plan to do some of this features in nearest future. Could you please copy your message to disscussion http://www.jetbrains.net/devnet/thread/282736 just to keep all things in one place.

0

Hello,

We've fixed one important problem with VB performance in nightly build 1277. I think it was the reason of 100% CPU usage in some cases. If you still have problems with busy CPU you can try this build.

Best Regards,
Olga

0

Olga Lobacheva wrote:

Hello,

We've fixed one important problem with VB performance in nightly build 1277. I think it was the reason of 100% CPU usage in some cases. If you still have problems with busy CPU you can try this build.

i have installed the build yesterday and worked with nearly no problems. Performance is good now even on my old PC in the office.
There is a problem with inserting live templates. I tried to surround a code region of around 700 lines with a try..catch block. The
template for this job i have written myself. R# has updated a JIRA issue with a 110... number for this problem (sorry i didn't
remember the exact number).

Regards
Klaus

0

I think I found this issue in jira - http://www.jetbrains.net/jira/browse/RSRP-106328. Is this problem reproducable?

0

Hi, Klaus,

Thanks for your feedback. I've reproduced this exception and changed priority of this issue to 'blocker' in our bug tracker - http://www.jetbrains.net/jira/browse/RSRP-98673.

0

while working with the latest EAP builds it seems that the editing performance for builds with even build numbers is slower than for builds with odd build numbers. I tried 1278, 1279 and 1280. Using 1278 and 1280 the editor hangs sometimes while CPU performance is high. With build 1279 the editor reacts always quick regardless of the CPU performance. I tried all three builds with the same file and made the same changes to the source code. The difference is significant. It seems as if there is a fix in 1279 which is not in 1278 or 1280. I'm curious about build 1281 to see it's performance.

Regards
Klaus

0

Funny idea. =) There are only two changes since 1278 build. Both seem to be really minor. Tell us please if problem  remains.

Regards,
Olga

0

the reason for my idea is that i've seen software companies which worked on several trunks of an application and published previews from the trunk which was stable at the time the preview was build ;-)

I installed 1281 this morning and worked half a day with it. I didn't see any hangs in the editor. Let's see what the next builds bring up :-))

Regards
Klaus

0

Please sign in to leave a comment.