views:

197

answers:

3

Is there some reason that identical math operations would take significantly longer in one Silverlight app than in another?

For example, I have some code that takes a list of points and transforms them (scales and translates them) and populates another list of points. It's important that I keep the original points intact, hence the second list.

Here's the relevant code (scale is a double and origin is a point):

public Point transformPoint(Point point) {
  // scale, then translate the x
  point.X = (point.X - origin.X) * scale;
  // scale, then translate the y
  point.Y = (point.Y - origin.Y) * scale;
  // return the point
  return point;
 }

Here's how I'm doing the loop and timing, in case it's important:

      DateTime startTime = DateTime.Now;
  foreach (Point point in rawPoints) transformedPoints.Add(transformPoint(point));
  Debug.Print("ASPX milliseconds: {0}", (DateTime.Now - startTime).Milliseconds);

On a run of 14356 points (don't ask, it's modeled off a real world number in the desktop app), the breakdown is as follows:

Silverlight app #1: 46 ms

Silverlight app #2: 859 ms

The first app is an otherwise empty app that is doing the loop in the MainPage constructor. The second is doing the loop in a method in another class, and the method is called during an event handler in the GUI thread, I think. But should any of that matter, considering that identical operations are happening within the loop itself?

There maybe something huge I'm missing in how threading works or something, but this discrepancy doesn't make sense to me at all.

+1  A: 

My first suspicion would be that Silverlight App #2 triggers a garbage collection. Scaling ~15,000 points should be taking a millisecond, not nearly a second.

Try to reduce memory allocations in your code. Can transformedPoints be an array, rather than a dynamically grown data structure?

You can also look at the GC performance counters, but simply reducing the memory allocation may turn out to be simpler.

Igor ostrovsky
Originally, when I created the rawPoints list, I also added each point to the transformedPoints list, so they would always be the same size and there would be no memory allocation over the run of the program. As far as I know, there is no performance difference between arrays and Lists if the size of the list never changes.
Klay
Also, this doesn't give any indication why the two apps would perform so differently.
Klay
A: 

Could it be possible your code is not being inlined in the CLR by the app that is running slower?

I'm not sure how the CLR in SL handles inlining, but here is a link to some of the prerequisites for inlining in 3.5 SP1.

http://udooz.net/blog/2009/04/clr-improvements-in-net-35-sp1/

Jeremiah Morrill
+2  A: 

In addition to the other comments and answers I'm going to read between the lines a little.

In the first app you have pretty much this code in isolation running in the MainPage constructor. IWO you've create a fresh Silverlight app and slapped this code in it and thats it.

In the second app you have more actual real world stuff. At the very least you have this code running as the result of a button click on a rudimentory UI. Therein lies the clue.

Take a blank app and drop a button on it. Run it and click the button, what does the button do? There are animations attached to visual states of the button. This animation (or other animations or loops) are likely running in parrallel with your code when you click the button. Timers (whether you do it properly with StopWatch or not) record elapsed time, not just the time your thread takes. Hence when other threads are doing other things (like animations) your timing will be off.

AnthonyWJones
This is what I suspected was the case. Work being done by another component or another thread is slowing down my math operations. The only other control on the page is an ESRI Silverlight map that's also responding to the mouse movements that are causing the re-drawing of my points. But computers are *really* fast--whatever it's doing should not be eating up so much processor time that it causes some fairly simple math ops to grind like they are...
Klay