Question

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.

Answer 1

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.