通过

Performance Scenarios

  • 项目

Perf for an editor is extremely important. Because editing is completely interactive, you really don't want a noticible delay in most cases. 

One of the first things to decide is what kinds of things you want to measure. Here's the list we're working on today, for Whidbey.

  1. Binding:
    1. Dot (time to show a completion list)
    2. quickinfo (time to show a tooltip)
    3. parameter help (time to show paramhelp tooltip)
    4. goto definition (time to navigate to the definition)
  2. Free Typing (just typing normally, editor should keep up)
  3. scrolling (stresses the colorizier)
  4. Proj Load
    1. Time to type (how long until you can start using the editor)
    2. time to dot list (how long until completion lists are 100% populated)
  5. Refactoring:
    1. Rename
    2. ExtractMethod
  6. Outlining (time from when a file is opened until when the outlining is done)
  7. Error reporting (populating the error list & clearing it up)

 

For each of these items, we set goals & measure the product performance regularly. If we don't meet goals, it's a bug to fix.

 

Obviously, it's worth including tests for things you know are fast enough already. If they're important, you don't want them to regress.

 

The above list is the Pri 1 list. It's the things we absolutely gotta get right to ship. I'm also not mentioning hardware configurations, source & solution characteristics.

 

Think about your experience with the C# editor. Are there other things that are important for you that we get fast enough?

Comments

  • Anonymous
    March 09, 2004
    VS.NET seems to fly. I ran the beta on a P2@350MHz with Win98 (with lots of RAM) and it worked ok. For $500 I picked up a P4 3GHz with 0.5GB RAM. I notice that completion lists sometimes aren't ready, but if I retry in a second they're done. No big deal.

    My slowest things are source control (it's over the net), help (switching content sets (.NET to Platform SDK to Internet Development) take way too long), and the Win/Web Forms designer (sluggish when switching around). This is on a P4c, 3GHz, 1.5GB RAM, 7200RPM drive with 8MB cache. I'm gonna get some SATA RAID0 going on soon, so hopefully that'll take care of MSDN help.

    I'd love for some visuals to be cleaned up (really long parameter lists, for instance) than any performance issues. I know some people can't find $100 for more RAM, but I don't think it's worth catering to them.
  • Anonymous
    March 09, 2004
    I have to admit there are none as far as the C# editor is concerned. The thing that takes most time for me is switching around like mentioned above but I guess we can't blame you for that.
  • Anonymous
    March 15, 2004
    F1 MSDN Help loading speed, and of course SourceSafe integration, of which SourceSafe is the culprit, not VS.NET.
  • Anonymous
    May 31, 2009
    PingBack from http://indoorgrillsrecipes.info/story.php?id=1551