Geeks With Blogs

News

  

Bill Evjen's Blog Code, Life and Community

Jan Gray – Architect //blogs.msdn.com/jangr

Abhi Khune – Development Lead //blogs.msdn.com/akhune

 

  • Slow Software Stinks – Don’t Ship It!
    • Symptoms – Locked-up UI, bad citizenship, poor scaling
  • Causes
    • Mistakes in architecture, reuse, interfaces, data representations, algorithms
    • Not paying attention; low prioritization
      • Where are we? Where should we be?
  • Is premature optimization the root of all evil?
    • How to optimize the right stuff, the right amount, at the right time?
  • Put Perf in Your Process – A discipline that works
    • “That which gets measured gets done”
    • Set goals; measure; know your platform
    • Perf budgets, goals and automated tests
    • Process of “continuous” improvement
      • Measure, track, trend, refine
      • Cut failures
    • Build a performance culture
      • User expectations
      • Developer attitudes – perf is my feature!
    • Read – Rico Mariani, Thinking about Performance
  • Moving to Managed Code
    • Why? Productivity and quality. It is a nice step forward for development. Can have less lines of code.
      • Do more with less code
      • Fewer bugs
      • Clean, modern libraries targeting modern requirements
      • Better software, sooner
    • But is performance a problem?
      • Perception vs. reality
  • Managed Code – close to the machine
    • Raw managed code speed rivals native code speed
    • JIT compiler --> optimized native code
      • Constant folding; constant and copy propagation; common subexpression elimination; code motion of loop invariants; dead store & dead code elimination; register allocation; loop unrolling; method inlining
  • Demo of Quake running in managed code – that is nice and the performance point was taken.
  • Demo of populating 10,000 nodes comparing C# and C++. The C# demo was faster due to the memory allocations done in C++.
  • Managed Code – Close to the machine
    • Low level cost model
      • Jan Gray, Writing Faster Managed Code: Know What Things Cost, MSDN
    • OK, so it’s fast – but there are setbacks
      • Startup time, working set
        • Loading MSCORWKS, MSCORLIB, System.*.dll
        • JIT-compiling startup code path methods
      • We’re working on it!
  • Yet Great Performance is Elusive
    • The challenge of fast managed code
      • We’re all newbies in managed code land
      • Learning how – not learning how much
      • Don’t know what things cost
      • Everything is easier. …
    • The trick is to recognize, avoid pitfalls
      • New managed code pitfalls
        • E.g. automatic memory management surprises
  • Know your Garbage Collector
    • Why should I care?
    • GC concept
      • Automatic – no error prone manual freeing
      • Recycles useless unreachable objects
      • new Type triggers a GC; pause thread(s); trace & mark reachable objects from roots; compact live objects; recycle dead objects
    • Self tuning
    • Generational GC
      • Most objects are temporary, die young
      • Partition heap into generations
      • New objects born in gen0 … gen0 is were live objects are born
  • Know your GC (2)
    • Generational GC Heap
      • Gen0 – new objects
        • Cache conscious; very quick
      • Gen1 – objects promoted during gen0 GC
      • Gen2 – long live objects, promoted during gen1 or gen2 GC
      • Large object heap
    • Workstation GC
    • Server GC
      • NUMA friendly; parallel; ASP.NET/hosted
    • READ: Jeffrey Richter, GC in .NET, MSDN
  • GC Pitfalls
    • Object lifetimes still matter!
    • Use an efficient “allocation profile”
      • Short lived objects are cheap (but not free)
      • And long lived objects don’t cause GC pressure
      • But don’t have a “midlife crisis” (avoid gen2 churn)
      • Review with perfmon counters, CLR Profiler
    • Most common pitfalls
      • Inadvertently referencing “dead” object graphs
        • Null out object reference (where appropriate)
      • Implicit boxing
      • Pinning lots of young objects
      • GC.Collect considered harmful – this interferes with the normal automatic process
      • Finalization …
  • Finalization
    • Finalization: ~C()
      • Native resources clean up – nondeterministic
      • GC; object unref’d; promote; queue finalizer
      • Costs: retians object and its object graph; finalizer thread; bookkeeping; call
      • Expensive – use sparingly!
      • Try to refer only to the native resource
    • Dispose pattern; implement IDisposable
      • Dispose: clean up, call GC.SuppressFinalize
      • Call Dispose early, when possible (C# using)
  • Pitfall: Indiscriminate Code Reuse
    • Your choices determine your perf
      • Your architecture, algorithms, …
      • Your uses of .NET FX types and methods
    • We keep seeing poor choices
      • No API is cheap enough to use everywhere
    • Does ease of reuse cloud our judgment?
      • The useful friction of native code reuse
    • You have to do your homework
      • Measure, inspect the time and space costs of your platform APIs, in your setting, in your hot spots
  • Data Pitfalls
    • Data locality
      • GC: objects allocated together in time will stay together in space
    • Data representation – XML
      • Finally, a universal solvent …
      • “It’s not just for interop anymore”
      • Uncompetitive performance compared to binary record formats
        • System.Configuration may read and parse 100s of KB of XML to find a few flags settings
      • Fashionable – or fast?
  • Reflection pitfalls
    • Powerful dynamic metaprogramming facilities
    • GetType is fine, but is, as even better
    • GetMember/Method/Field, Get/SetValue, Invoke, CreateInstance
      • ~100x slower than the direct way
      • Footprint of metadata and reflection
  • P/Invoke, COM Interop Pitfalls
    • Embracing legacy native code reuse
    • Efficient, but frequent calls add up
    • Costs also depend on marshaling
      • Primitive types and arrays of same: cheap
      • Others, not; e.g. Unicode to ANSI strings
  • Deployment Pitfalls
    • Assemblies
      • Units of deployment, encapsulation, CAS, versioning, servicing, loading, separate authoring – so man dimensions!
      • Performance-wise: the fewer, the better!
    • Know which assems are loaded, when and why
    • GAC install your signed assemblies
      • Avoids repetitive SN signature verification
    • NGEN – ahead of time native code generator
      • Caches native code image DLL
      • May reduce startup time, improve page shareability
      • (Currently) code may run slower
      • Try it and measure yourself
      • Beware rebasing, other native image load failures
      • Much improved and simplified in VS 2005
  • Microsoft is making HEAVY investments in NGEN for Whidbey
  • Analyzing Performance Problems – Code Inspection
    • Ildasm – findstr “box”: Great tool to get the cost for the API.
    • Debuggers – Module loads, rebasing: Can look at all the assemblies that are being loaded. Can show you the actual JIT code. Look at JIT optimizations.
    • FxCop – Static Analyzer: Looks at code and can give you performance warnings.
  • Measure it with tools
    • High level diagnostics
      • Taskmgr, perfmon, vadump, event tracing for Windows (ETW)
    • Time
      • Code profilers, timing loops, ETW
    • Space
      • CLR Profiler, UMDH, code profilers, ETW
  • Should have 100 gen0 collections/10 gen1 collections/1 gen2 collections
  • Some VS 2005 CLR Perf Work
  • Cheaper AppDomains, faster cross-AD calls - ~1.1x-50x faster
  • Faster delegate create (~10x) and invoke (~2K)
  • Generics and new collections
  • Lightweight Reflection.Emit
  • GC Improvements - Memory pressure API, Less fragmentation due to pinning
Posted on Thursday, May 27, 2004 1:40 PM Microsoft | Back to top


Comments on this post: TechEd 2004 - DEV491: .NET Framework – Writing Faster Managed Code

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Bill Evjen | Powered by: GeeksWithBlogs.net