Awkward Coder

Looking to eek-out as much perf as I can from some code (C#) at work, and looking at all the .ToString() manipulations in the code and I came across the following: How can I quickly workout if I want to do something around this? BenchmarkDotNet to the rescue, and this library really does make benchmarking easy (and fun!). I created an overload of the extension method which internally uses a cache to avoid the repeative ToString() calls: Only small issue was wanting to test a Static methods, and this only involved creating a wrapper class with annotated methods(calling the static implementations), also preloaded the internal cache: Results below, make-of-it what you will...

Not blogged for an age, and I received an email last week which provoked me back to life. It was a job spec for a WPF contract where they want help sorting out the performance of their app especially around grids and tabular data. I thought I'd shared some tips & tricks I've picked up along the way, these aren't probably going to solve any issues you might be having directly, but they might point you in the right direction when trying to find and resolve performance issues with a WPF app. First off, performance is something you shouldn't try and improve without evidence, and this means having evidence proving you've improved the performance - before & after metrics for example. Without this you're basically pissing into the wind, which can be fun from a developer point of view but bad for a project :) So, what do I mean by ' Dispatcher thread performance '? The 'dispatcher thread' or the 'UI thread' is probably the most ...

Currently I'm working on a .Net 4.0 WPF app and we've had some discussion about moving to .Net 4.5, we don't get to make the decision :( but we're interested to know what performance gain we'd get. What follows is a comparison of the same app compiled against .Net 4.0 & 4.5. The app makes use of a couple of NuGet packages - Autofac & Reactive Extensions, both of which provide versions for both .Net 4.0 & 4.5. It also makes use of Telerik grid control to render the data. What does the app do? Pretty simple, it generates a 1000 rows of data asynchronously and binds this to a telerik grid, for every iteration the grid is clear of any data first. How am I going to measure any performance improvement? I'm using the code from a previous post - ' Measuring UI Freeze... ', I'm expecting any improvement to be visible in a reduced amount of time on the dispatcher thread - if the (.Net) code base is more efficient it should surely redu...

In a previous post I talked about the how the use of an ORM would have saved development time. Having made the statement I thought I would share how the UI service layer we introduced still received a considerable benefit from the introduction of an in-memory cache. The constructor for the service is shown below, as you can see pretty standard really, the interesting interface is the ICacheProvider. As I said in the previous post this service interface and implementation would not exist if an ORM had been used. The ICacheProvider interface is literally an abstraction around the  MemoryCache  provided by .Net framework, this then allowed a null caching provider to be defined as well as testing isolation. public interface ICacheProvider { bool Add ( CacheItem item , CacheItemPolicy policy ) ; object AddOrGetExisting ( string key , object value , CacheItemPolicy policy , string regionName ) ; bool Add ( string key , object valu...

If you've been developing Windows Phone 7 apps you'll be aware of the '90 MB' memory limit guideline detailed in the application certification requirements , if not it says: 5.2.5 Memory Consumption An application must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory. You can use the DeviceExtendedProperties class to query the amount of memory that is available on the device and modify the application behavior at runtime to take advantage of additional memory. For more information, see the DeviceExtendedProperties class in MSDN . I've heard of apps exceeding this limit and still being approved for the app store, but that is not the point of this post , the point is as a developer working on a device you should have a cursory knowledge of the size of your data. The reason is simple because when you exceed the 90 Mb limit (and in all probability you will) you'll be able to identify where your memory problems are quicker an...