I was chatting with some of the people on our performance team (i.e. the people who are supposed to make sure VB is as speedy as possible), and they were talking about some plans they were considering to help gather public feedback on problem areas in the product. “What about the MSDN Product Feedback Center?” I asked. “We hadn’t thought of that,” they replied, “perhaps you should blog about it!” So consider it done. I am now officially encouraging everyone to report any major performance problems you’re having with VB using the MSDN Product Feedback Center.
To ensure that your bug gets the amount of attention due it, here are several suggestions:
- Put the word “Performance:” in the title of the bug.
- Include the general hardware specifications (CPU speed, memory, etc.) that you’re testing on.
- Include any changes to the environment that you’ve made (i.e. what tool windows are showing, which profile you are using, etc.).
And, most importantly:
- Include specific steps that will allow us to easily reproduce the problem.
The last point is important to ensure that we actually can do something in regards to your bug report. Saying “the product is slow,” isn’t going to help us. Saying “when I show the Autos window and then hit the Step Through toolbar button on this code, it takes several seconds.” is more like it. Remember, the more specific you are, the higher chance we’ll be able to fix the problem.
I’m also talking to Robert Green to see if we can’t get a specific “Performance” Problem Type added to the Feedback Center to help categorization. The wheels grind slowly, though, so it may be a while on that one.
Just to clarify in my mind. Are you referring to just the VB language or does it also include the IDE?
Both! (Feel free to submit bugs for other products too… I mean, aren’t performance problems bugs?)
Talking about performance, there’s a question I’ve been meaning to ask for a while. Is there any performance advantage in using With if the object is early bound e.g. any difference between the following or will the compiler produce the same code?
If .txtRects.Enabled = False Then .txtRects.Enabled = True
If Me.txtRects.Enabled = False Then Me.txtRects.Enabled = True
They won’t produce exactly the same code – the With statement will still capture the value of Me to a temporary variable and load it from there. The difference is so negligible that I doubt you’d ever notice it, but I’ll make a note to see if we can’t optimize the situation since Me can never change.
Thanks for the reply.
Referring back to a previous post where you asked for suggestions for major improvements to the VB language, I would like to make 2 more suggestions.
The first is to make the regular expressions language more VB like. I often use regular expressions, but not enough to make me an expert. I always use a toll to help me test them, but still end up with all these brackets, backslashes, question marks etc. that make it difficult to understand the meaning of the expressions. Additionally, as these will then be enclosed in quotes, there is no compile time checking. Therefore making them first class members of the VB language and making the syntax more VB like would be very useful. I suspect that are a lot of people that don’t currently use regular expressions because of the difficulty involved.
My second suggestion is the rewrite the Access report writer for use in VB. The Access report writer is just so much better that the current solution. If you ask Access developers why they use Access rather than VB the number one reason is the report writer.
Thanks for the suggestions, Alex, we’ll consider them!