Over-updating…

February 24, 2006 at 12:23 am

Raymond writes an interesting post about how some programs run faster if you hold down the mouse.


This is a classic situation to get yourself into – I’ve probably seen it 5 times, and hit it again recently.


When we’re burning a DVD, the burn engine calls back into the UI layer so that we can update the progress bar. To give the user a single monotonically-increasing progress bar, we (well, Dean, actually) have to play some games with our progress tracking, which means that sometimes we get progress callbacks once a second, and sometimes we get them 100 times a second.


The progress dialog looks fine, but if you look a profile of the burn, you’ll find that a fair amount of time is being spent in the UI code updating. In this case, it’s not a big deal, but I’ve seen cases where programs are spending 90% of their time updating the UI. That takes a 10 second operation and makes it take 100 seconds, which is pretty bad.


The fix? Well, there are two good ones.


The simplest one is to simply update every <N> calls. I traditionally start with N=10, which is guaranteed to same 90% of the overhead, and usually works fine.


If your callbacks are sporadic – as they are in the DVD Maker case – it works better to timebox the updates. Whenever you update the UI, record the time, and then don’t update it again until a specific time has gone by. I usually find 1/4 second to work well.


 

Resistance to pairing

February 3, 2006 at 11:54 am

Paul wrote an informative response to my post on collaboration.

I’ve just been writing some stuff about where I think our group should go in the future, and I’ve decided to downplay pair programming. Not because I think it’s a bad idea, but more because I think that opinions around it tend to be a bit religious.

Instead, I’ve decided to advocate an open environment where pairing can happen in a natural way

Bicycle Climbs of Seattle, Eastside Edition

June 16, 2005 at 12:24 pm
Spent a bit of time polishing up my google maps application last night, and it’s ready for public showing.
This is based on an idea I’ve had percolating away in the back of my mind for a few months now…
That takes you to a google map which shows a fair number of climbs around these parts. Click on a climb, and you’ll get a popup with some data about the climb, and click on the name of the climb to go to the detail page.
I feel fairly confident that the length and elevation gain data is correct, and therefore the average gradient is likely to be pretty good as well. The maximum gradient – well, I’ve taken that from the steepest parts of the gradient plot, but there is certainly some chance for error there. Not only do the roads on Topo USA not conform to actual contours (which definitely messes up the gradient plot on any climb with switchbacks), their topo data may also not take into account that grading that takes place during road construction.
I’m looking for:
  • General comments and suggestions
  • New climbs to add, both on the eastside and in Seattle and elsewhere
  • Better data for maximum gradients
  • Descriptions for the climbs.
  • Rankings for the climbs. I currently have green, yellow, and red. I’m going to add something beyond red for climbs like the zoo, but if you think I’m off on the relative ranking of climbs, let me know.
(Technology stuff)
This was originally going to be all generated on the fly, but I’d forgotten how much of a pain it is to work with a database on a web server. So, the data lives in a database on my machine, and there are a set of C# scripts that generate both the detail pages and the xml to drive the google maps page (yes, I know, how 1998 of me). The maps and gradient plots are hand-extracted from Topo USA.

How To Do A Good Performance Investigation

May 27, 2005 at 8:56 pm

More sage words from Rico…


And a followon

Jay and Properties…

April 29, 2004 at 9:55 pm

Jay wrote a post entitled Properties? Not my bag, baby.


When I first started writing C# code, I used properties for everything. But recently, I’ve felt that I was wasting a lot of time writing trivial properties. Yes, I know that in Whidbey I’ll be able to use expansions to write them easily, but that still means that I have to deal with the property bodies cluttering up my code.


So, that got me thinking about whether it makes sense to be writing properties in the first place. After a bit of thought, here’s my current position:


Properties are a great thing for component libraries. There are certainly cases where you would want the future-proofing and decoupling that properties gives you.


But when you’re working on a single project that gets built all at once, I don’t think you’re getting any future-proofing benefits, and you have to pay the “property tax” the whole time.


This may be heretical, since “use properties” has been the common guideline.


What do you think?

Taking it to the next level…

April 15, 2004 at 9:21 pm

Josh writes:


I’ve been working professionally with C# for about 2 years now and am just blown away by the things I can do with it. Lately though, I’ve felt like I’ve plateaud at this beginner to intermediate level. Every book I look at is either “Hello, World” or beyond my level of expertise, I feel like I’m always one step behind the game and my code is becoming stale.


That’s a very interesting question. I’m not longer a professional programmer (though I was for a little over a decade), so you’ll also want to listen to the comments that others are sure to write.


If you haven’t read them, there are a couple of books that I’d definitely recommend.


Code Complete
The Pragmatic Programmer


Both of these are currently on my bookshelf (actually, they would be if somebody hadn’t walked off with my copy of Code Complete).


To expose yourself to some new ideas, I’d also suggest:


Refactoring: Improving the Design of Existing Code
Extreme Programming Adventures in C#
Test-Driven Development in Microsoft .NET


Whether you agree with these approaches or not, they are certainly thought-provoking.


The best programmers that I’ve known always have a few side projects going on, where they’re exploring new areas, new environments, etc. If you’ve never done network programming, try writing some socket code, or play around with remoting, or DirectX. Play around with tools, like a profiler, or measure the performance of different options. Get a book on .NET IL and spend some time under the covers (Richter’s book is a good guide here).


Finally – and this may seem like weird advice from a C# guy – spend some time writing some code in a language such as Perl. Scripting languages lead to a different mindset that can be useful in language.

Pragmatic Unit Testing in C# with NUnit

April 13, 2004 at 7:59 am

I got this reference from http://www.theserverside.net, but since they require login to get to the link, I’ll instead refer you to the book page


I took a look one of the sample chapters, and I thought it looked pretty good, except for the fact that the first interface in the chapter is named “Environment” (the others are fine). 

How do you look for code?

December 4, 2003 at 12:27 pm


Another question, this time from one of the other PMs on the team:

The C# team is trying to understand how you look for code when stuck or trying to
learn some new technology. Currently the solution we provide is in the documentation
– you can find among other things –

  • Walkthroughs on the product
  • Documentation for each method
  • How to articles that target specific tasks
  • Code snippets
  • Working pieces of code that we ship in the product that do a specific task.

How do you try to find code for a task that you don’t know how to write? Is the Help
content in VS organized well and is it adequate? What would you change to help
people ramp up on new code, tasks, or the capabilities of the tool faster? What annoys
you about the samples we provide today?

 


Don’t write code like this…

October 21, 2003 at 7:22 pm

I’ve just finished doing a security review of my MSDN columns, and as part of that,
I needed to add some security to an add-in architecture, so the add-in architecture
won’t run antisocial code. The approach taken by .NET security is reminiscent of ACLs,
which means (at least to me) that it’s confusing and I need to read the code 5 or
6 times before I understand it. Along the way, I got a chunk of code from somebody
on the .NET security team, which I’ll reproduce here:

private NamedPermissionSet FindNamedPermissionSet(string name)
{
	IEnumerator policyEnumerator = SecurityManager.PolicyHierarchy();

	while (policyEnumerator.MoveNext())
	{
		PolicyLevel currentLevel = (PolicyLevel)policyEnumerator.Current;

		if (currentLevel.Label == "Machine")
		{
			IList namedPermissions = currentLevel.NamedPermissionSets;
			IEnumerator namedPermission = namedPermissions.GetEnumerator();

			while (namedPermission.MoveNext())
			{
				if (((NamedPermissionSet)namedPermission.Current).Name == name)
				{
					return ((NamedPermissionSet)namedPermission.Current);
				}
			}
		}
	}
	return null;
}
    

Ugly, isn’t it?

The root of the problem is that PolicyHierarchy returns an IEnumerator instead of
an object that supports IENumerable.  This means that I can’t use foreach on
it, and have to write the traversal myself. This decision also means that, without
a collection returned, there’s no place to hang a useful method like “LookupLabel()”
on, so all users are stuck writing the search code themselves (or encapsulating it
off into a separate method).

PolicyLevel.NamedPermissionSets uses a different approach, that of returning an IList,
which is better than an enumerator, as I could use foreach on the IList, but the person
who wrote this sample didn’t because they didn’t know about foreach. If they had,
they would have done the right thing.  

We need to not do this.

 

Building a music system

August 16, 2003 at 12:09 am

We have a ski place in Skykomish, WA (20 miles from Stevens
Pass
) that my wife and I have been finishing for the past couple of years (contractor
did the shell to painted drywall, we do everything else). Having music while doing
this is a critical factor, so I brought an old stereo (my first receiver, in fact,
from 1980) and a 5 disk CD changer up there. That’s has worked okay, but when your
used to having all your CDs (somewhere around 200) accessible and automatically scheduled
with your PC-based system, you kindof get tired of the same 12 CDs. (Yes, I know,
I *could* bring up more, but that would require me to plan ahead, and I still wouldn’t
bring up the right one).

I did some research into CD jukeboxes, and wasn’t terribly impressed. They’re a bit
smaller than a PC, but all they do is music, and they don’t implement the system that
my home-based on does. So I held off on buying one.

I’ve recently been working on a C# version of my system, and it’s starting to wake
up and look around, and it’s almost good enough to use. So I decided to build a small
PC to hold my music and run the software.

I started at NewEgg, who supplied the components
for my current office system. I wanted a minimal system with a reasonable size disk
and network. A little research got me a motherboard, case, cd-rom, memory, processor,
fan, and hard disk for $328 to my doorstep. One trip to the computer store to get
another IDE cable and to get a fan that would actually *fit* in the case (its a
micro atx size). That’s a pretty good price for an Athlon 1500, 256M of memory and
40 Gig of disk space.

So, once I get XP on the system, I’ll copy the files over, and probably install the
current version of my software. One problem with the system is coming up with something
that isn’t a big ugly PC. The Micro ATX case helps a bunch, but what do you do with
the monitor and keyboard? My real home system uses IR remote control, which is a possibility,
but the new system also supports using a PocketPC as a controller. At work I use a Toshiba
e740
with built-in wireless as the test for remote control, and it works great,
but I’m not going to use a $500 PPC to control a $330 music system. I needed something
cheaper. I decided to forgo the wireless and bought a reconditioned Toshiba e310 on
ebay for $125, and I’ll use that in the cradle as a remote control (I hope. I think
I can get this to work over the USB, but I haven’t actually tried it yet).