hacked.brain

ASP.NET AJAX “Disposable Objects” Performance Heads Up - Part II

2009-04-13T20:44:11Z

Ok, I had to put together a Part II to this topic because I was totally wrong in Part I about objects being able to be used as keys because… well, I’m an idiot and didn’t do all my fact checking to make sure my implementation was 100% sound. :) Thanks to Dave Reed who commented on the original post pointing out my flawed thinking.

Mea culpa

Basically Dave points out that JavaScript objects are really specialized hashtables called associative arrays where the keys absolute MUST be a string OR a type which can be converted to a string. Now because we’re using Object subtypes here, they would have to override the toString() method to provide a meaningful string if we expected them to be used as keys. Well, the instances we were stuffing in the _disposableObjects weren’t providing any such toString implementation, nor do we want to impose one. So, is all lost? No!

Redemption!

Ok, so I totally failed with my first approach, but I shall now redeem myself! As soon as my other idea was beaten down, set it on fire and stomped it out with golf cleats (actually Dave was rather nice, it just FELT like that’s what happened), I quickly came up with another solution. Here’s the nitty gritty:

Sys._Application keeps an internal counter called _dispoableObjectsNextId which is started off at the minimum value of a 32-bit integer number:-2147483648. I choose this for ease and because it will provide us with billions of identifiers which, unless your app runs for a really long time and/or instantiates and disposes of billions of objects should have us covered.
Sys._Application has a constant hanging off of it called _DisposableObjectIdKey which I’ve decided to make "!!disposableObjectId". I don’t see that colliding with many other chosen JavaScript key names, but because it’s a constant we could change it to be something long and totally ASP.NET AJAX specific to avoid the possibility of collision.
Each time Sys._Application::registerDisposableObject is called we “tag” the incoming object with the next identifier using the constant _DisposableObjectIdKey. Next we use that identifier as the key on the _disposableObjects hashtable with the object as the value.
When Sys._Application::unregisterDisposableObject is called we look up the value of the id on the incoming object using the _DispsosableObjectIdKey we then delete that key from the _disposableObjects hashtable.
For the Sys._Application.dispose implementation we simply for..in the keys on the _disposableObjects hashtable and call dispose item that is registered.

The new performance picture

We’re doing a little more than before here, so naturally we’re gonna take a hit someplace. How bad is it? Do we still outperform the array?

IE 6.0.2900.5512.xpsp.080413-2111

# of Objects	Array (ms)	Hashtable (ms)	Gain
500	160	1(+0)	160x
1000	711	10(+0)	71.1x
5000	*33298	90(+9)	369.9x
10000	*138279	180(+19)	768.2x

IE 8.0.6001.18702

# of Objects	Array (ms)	Hashtable (ms)	Gain
500	91	5(+1)	18.2x
1000	429	11(+2)	39.0x
5000	*27168	57(+10)	476.6x
10000	*110025	114(+10)	965.1x

FireFox 3.0.7

# of Objects	Array (ms)	Hashtable (ms)	Gain
500	21	1(+0)	21.0x
1000	79	2(+0)	39.5x
5000	1891	11(+0)	171.9x
10000	7608	22(-1)	345.8x

Safari 4 Public Beta (5528.16)

# of Objects	Array (ms)	Hashtable (ms)	Gain
500	63	1(+0)	63.0x
1000	263	2(+0)	131.5x
5000	6805	5(-4)	756.1x
10000	*28315	12(-6)	1573.1x

*Indicates that I had to escape the “Slow running script” dialog to even be able to continue execution on these.

Well, we’re still handily out performing the Array implementation. We took hits in both IEs, but the hit was worse in IE8 which is absolutely baffling. FireFox didn’t really change, in fact the 10000 object test gained a millisecond. Finally, Safari 4 gained in the 5000 and 10000 object tests!

Is this a hack?

So, some will look at this and say: hey man, that’s really hacky that you’re just slapping a random key/value (aka “expando” property) on an arbitrary JavaScript object like that. Wellllll, this is JavaScript and from where I’m standing that’s one of the powerful features of this language. It’s kinda like DependencyObject if you’re familiar with WPF. In most cases that I can think of this is perfectly harmless because, if people don’t know about it or purposefully go messing with it, it can’t hurt anyone. The only case where this could potentially hurt is if someone’s implementation uses a for..in on the object to enumerate all of its keys. That would now turn up our _DisposableObjectIdKey and that could be bad. There is only one aspect of the framework that really does that and that’s when working JSON [de]serialization. In the case of JSON objects though, you’re talking about “pure” data objects and those are not going to be registered as “disposable objects” anyway. So, the real question for me is: Is this “hack” worth the performance gains as long as it comes with a small documentation note that explains how this extra field could affects callers? And for me, the answer is “hell yes”.

Conclusion

Ok, so I screwed up my first approach, but hopefully this second one helps me save some face. We had to do a little extra work inside the framework code base and gave up a wee bit of performance in IE, but we’re still posting huge gains over the existing implementation. I am providing my updated version of the performance test and framework scripts below and will go update the CodePlex issue with this latest version as well. Now, I just have to hope I got it right so Dave doesn’t come back and teach me another lesson. ;)

Links

Download the updated performance test and framework scripts.
Still want to see this fixed? Go vote on the issue over on CodePlex.

ASP.NET AJAX “Disposable Objects” Performance Heads Up

2009-04-10T22:30:33Z

Update: Make sure you read Part II as there was ultimately a fundamental flaw in this implementation which prevents it from working as I originally thought.

One of the important features of the ASP.NET AJAX client side framework is the concept of disposing of components/controls so that they unregister event handlers and release DOM element references so that you don’t end up with circular references and, thus, memory leaks. The ASP.NET AJAX client framework takes the same approach as .NET does where there is a Sys.IDisposable interface which you can implement to indicate that your class requires disposal semantics. By implementing this interface certain aspects of the framework, as well as other consumers of your code, will recognize that they need to call your dispose implementation.

How the framework tracks “disposable objects”

The performance problem I want to discuss lies in the way the framework itself tracks known instances of “disposable” objects. First off, anything that derives from Sys.Component is automatically in this boat. Sys.Component is important because it is the base class of other important base classes like Sys.UI.Control and Sys.UI.Behavior. Sys.Component implements Sys.IDisposable, but also has some tight coupling with Sys.Application. Every time you create an instance of a Sys.Component a call is made during its initialization to Sys.Application.registerDisposableObject to which it passes itself in. This method takes whatever instance it is handed and calls Array.add to add the object to an array it maintains internally called _disposableObjects. Conversely, when Sys.Component’s dispose method is called it makes a call to Sys.Application.unregisterDisposableObject at which point the method calls Array.remove to remove the instance from the _disposableObjects array. The astute performance geeks are probably already starting to see where this is going, but before I get to the specifics let’s discuss why this register/unregister dance is even happening in the first place.

Why does it work this way?

So, why does Sys.Application need to even track these objects? Isn’t the person who created them supposed to dispose of them? Well, for the most part yes. However, there’s also the pattern of just creating controls via global functions, such as pageLoad, and then just forgetting about them. In either case, when the application is shutting down either from an explicit call to Application.dispose (which is rare) or a navigation away from the page it needs to be able tell all those objects that it’s time to clean up.

So what’s the problem?

Ok, so, what exactly is the problem? The problem is an array is used to store this list of disposable objects and, as mentioned earlier, when a component asks to be unregistered Array.remove is used. Array.remove uses Array.indexOf to find the position of the item in the list. Array.indexOf is implemented as a for loop indexing into the array and doing equality checks on each item until the item looking to be removed is found. So, the more disposable objects in the array the worse your performance gets. In Big-O Notation, we’re talking O(n) here. Worse yet is that, if you consider the typical pattern where the most recently created objects are the ones most likely to be disposed of, you’re constantly having to scan through to the end of the array. And that’s not all! Once Array.remove has located the index of the item in the array it still has to perform an Array.split to actually remove it from the array which incurs even more overhead.

Seriously, is this gonna even affect me?

Right about now, some of you might be skeptical and wonder why this is such a big deal. I mean, who creates all that many components anyway? Well, I can tell you I’ve already run into this problem in a rich client ASP.NET AJAX application in production. You see, the power (and joy IMHO) of ASP.NET AJAX is that you’re encouraged to create more complex interactions by composing controls and behaviors much the same as you would with WPF/Silverlight. You just have to keep in mind that each control and behavior you attach to an HTML element adds to the _disposableObjects array we’ve been talking about here. Worse still is that the power of templates which make it sooo easy to repeat a bunch of controls/behaviors per each item being bound. You always need to be aware of how many controls/behaviors each instance of a template instantiates of course, but you also need to consider that even binding some text to a <span> element comes with the same cost because Sys.Binding is a Sys.Component subclass.

A proposed solution

So, how can we remedy this problem? Sure sounds like a problem for a HashSet<T> to me in .NET land. Hmm… too bad there isn’t some kind of a hashtable implementation in JavaScript, right? Well, actually, there is! A lot of people don’t realize it, but every JavaScript Object is really just a glorified hashtable of key/value pairs. All we need to do is use the power of the ability to dynamically add key/values to any JavaScript Object using the [key]=value notation. Keys don’t have to be strings or numeric types, any type can! So, with that in mind, if the the internal _disposableObjects field on Sys.Application was just an Object and registerDisposableObject just added the instance being passed in as a key with null as a value and then unregisterDisposableObject just deleted that key from _disposableObjects, we could rely on the power of the JavaScript runtime implementation to find that entry in the list instead of having to scan the entire list looking for it ourselves. Now, naturally it depends on how the JavaScript runtime is implemented, but most implementations today are actually using “real” hashtables/hashcodes behind the scenes so the performance is wayyyyy better than having to index into an array and do equality checks ourselves.

Working code

As not to be all talk and no action, I’ve actually updated the latest version of the ASP.NET AJAX Preview (version 4 as of this writing) with these changes and am providing my updated copy at the bottom of this post. I’ve also relayed this information to Bertrand Leroy who is forwarding it to the ASP.NET AJAX Team who I hope will consider making the fix in the next drop since it’s completely internal to Sys.Application and very easily tested for compatibility. Just to make sure, I also entered an issue over on CodePlex which, if you’re interested in seeing this get fixed, you can go vote on.

Numbers don’t lie

Here’s a quick set of results from a performance test I slapped together where I instantiate some number of disposable objects and then dispose of them in reverse order to simulate the fact that, most often, the youngest of objects die off first. The machine where I ran these tests is a Core 2 Duo 2.66Ghz, 4GB RAM, running Vista 32-bit SP2. The IE6 test was done in the IE6 test VM supplied by Microsoft which is running XP SP3. The Safari test was done on a 13” MacBook with Core 2 Duo 2Ghz, 2GB RAM running OS X 10.5.6. All tests were done with the release mode version of the MicrosoftAjax script and the numbers shown are the median of three consecutive runs. I also executed the test several times before recording the numbers to give the JavaScript engines a chance to employ any kind of code optimization they might use.

IE 6.0.2900.5512.xpsp.080413-2111

# of Objects	Array (ms)	Hashtable (ms)	Gain
500	160	1	160x
1000	711	10	71.1x
5000	*33298	81	411.1x
10000	*138279	161	858.9x

IE 8.0.6001.18702

# of Objects	Array (ms)	Hashtable (ms)	Gain
500	91	4	22.8x
1000	429	9	47.6x
5000	*27168	47	578.0x
10000	*110025	94	1170.5x

FireFox 3.0.7

# of Objects	Array (ms)	Hashtable (ms)	Gain
500	21	1	21.0x
1000	79	2	39.5x
5000	1891	11	171.9x
10000	7608	23	330.8x

Safari 4 Public Beta (5528.16)

# of Objects	Array (ms)	Hashtable (ms)	Gain
500	63	1	63.0x
1000	263	2	131.5x
5000	6805	9	756.1x
10000	*28315	18	1573.1x

*Indicates that I had to escape the “Slow running script” dialog to even be able to continue execution on these.

No surprise that FireFox and Safari are crushing IE in both scenarios. It’s also no surprise that IE6 lags everyone else in both scenarios. Safari appears to have the best hashtable implementation of the three, though FireFox seems to have the best overall execution performance since it beats the others handily in the Array approach. One thing’s for certain, all the browsers show massive gains when moving to the hashtable approach.

Final thoughts

Assuming the ASP.NET AJAX team applies this simple change to the next version of the framework, there’s really not much to worry about going forward because even if you had an application with 10000 registered disposable objects and, at any given time, you dispose of a more realistic number of components, like say 200-300, from a template at once, the overhead of the unregisterDisposableObject implementation will now be so miniscule that all you have to worry about is the actual cost of the dispose implementations themselves.

Links

Getting a distinct list of changed files from TFS using PowerShell

2009-04-01T13:42:54Z

If you’re like me and need to do code-reviews of other people’s stuff or maybe you just want to see everything that’s changed during a certain period of a project, then here’s a nice PowerShell tip for you.

First, make sure you’ve downloaded the latest version of the Team Foundation Powertools. Starting with the October ‘08 release, the tools now include a PowerShell snap-in that add several commands which enable rich interaction with your Team Foundation Server. Of particular interest to us for this exercise though is the Get-TfsItemHistory command.

Now, let’s assume a scenario where we have a Team Project named $/Foo and we’ve been working on some patches in a v1.1 branch within that project. Now it’s time to review the work we’ve done in the current iteration which started on March 1st ‘09 and ended on March 31st ‘09. Here’s how we might start gathering those changes:

Get-TfsItemHistory “$/Foo/v1.1” -Version “D3/1/09~D3/31/09” -Recurse

Now, what this is gonna do is bring us back all the changesets that are related to any file underneath the v1.1 branch. While listing out the changesets is nice, it’s not going to tell exactly which source files I need to review. So the next thing we need to do is make sure we bring back all the changes in the changesets by adding the -IncludeItems parameter to the Get-TfsItemHistory call. We’ll also want to do is flatten out the list because, again, we’re interested in the indvidual changes, not the changesets themselves. So we use Select-Object’s -Expand parameter to flatten out the list:

Get-TfsItemHistory “$/Foo/v1.1” -Version “D3/1/09~D3/31/09” -Recurse -IncludeItems | Select-Object -Expand “Changes”

Great, so now we have a list of all the changes that were made to each file in this release, but this is still a little noisy. For starters, change types such as deletes, branches and merges are shown here. Well, if the file was deleted there’s not much to look at now, so… I don’t want those in my list. Also if a file was simply branched into the project from someplace else we don’t really care because wherever it came from already underwent a review. Merges are also questionable as, hopefully, the merged was reviewed for any conflicts at the time the merge occurred. Plus if there was a conflict that means they must have changed the file which will show up as a standalone edit anyway which means it will still end up on our list. So, how do we filter that noise out? Like so:

Get-TfsItemHistory “$/Foo/v1.1” -Version “D3/1/09~D3/31/09” -Recurse -IncludeItems | Select-Object -Expand “Changes” | Where-Object { ($_.ChangeType -band ([Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Delete -bor [Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Merge -bor [Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Branch)) -eq 0 }

Alright, almost there! Now the only problem is that if the same file is changed multiple times it’s going to be listed multilple times and really we just want the distinct names. This is a little tricky because the Change object contains the Item as a Note property, luckily there’s a Select-TfsItem command to help read what we’re interested in out. After that we just do a little grouping and sorting and we have a list we can work with:

Get-TfsItemHistory “$/Foo/v1.1” -Version “D3/1/09~D3/31/09” -Recurse -IncludeItems | Select-Object -Expand “Changes” | Where-Object { ($_.ChangeType -band ([Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Delete -bor [Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Merge -bor [Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Branch)) -eq 0 } | Select-TfsItem | Group-Object Path | Select-Object Name | Sort-Object

Finally, in true PowerShell fashion, this will write the paths out to the host (console or ISE), but naturally you could also Export-*, Out-*, etc as well.

IE JavaScript Debugging near useless when try/[catch|finally] is used

2009-03-27T20:35:27Z

As far as I can tell, IE JavaScript debuggers, such as Visual Studio or the new IE8 Developer Tool, have no ability to catch “first chance” JavaScript errors. Honestly, if I had to guess, this is probably because of some limitations of the JavaScript engine implementation more than the tools. Whatever the reason though, you run into a serious problems trying to identify where your errors are occurring if you have a try/catch/finally anywhere in the call stack.

If you just have a try/finally what happens is that the debugger will break with the current line of execution being the opening curly brace of the finally block. The entire stack where the error occurred is unrolled and you’re left with no context with which to debug:

A try/catch isn’t much better. Now the debugger won’t even break since you’ve handled the error, so you’re left having to make sure you have some sort of breakpoint or logging in all your catch blocks. What sucks even more is that the JavaScript Error class has no contextual information about the script that was executing (i.e. call stack, file name, line number, etc.). This isn’t Microsoft’s fault really, it’s just that whoever designed JavaScript thought it was important enough to have structured error handling but not to actually have any useful debugging information about the error that occurred. *sigh*

So right about now you’re probably all like “who the hell honestly uses try/[catch|finally] in JavaScript anyway”. Well, truth be told, I can’t think of a single time I’ve put it into my own code, but uhh… guess what does have it? ASP.NET AJAX. And guess where it is? Around the async callback code for the XMLHttpExecutor. Why is this such a big deal? Well, because it basically means if an exception occurs anywhere within the stack of the callback function you provide, you cannot debug it. Since one usually ends up executing a lot of code in response to ones data coming back, this is a total pain in the ass.

The good news is the latest ASP.NET AJAX previews have removed the try/finally. The bad news is that’s not RTM yet, so here are some options:

Debug with FireFox using FireBug. It does support first chance exceptions and will stop right where the exception occurs.
Plop a debugger; statement in your root callback function and step through/into the code line by line until it terminates. What sucks about this is you have to do it once to find out where it terminates and then do it again to actually avoid making the call that killed it next time so you can check out the state of things around you.
Pepper your source code judiciously with Sys.Debug.trace calls so you can figure out the last thing that happened before it tanked. Potentially a “good” thing anyway for tracing during testing, but definitely a pain in the ass to maintain and has a runtime performance impact that you’ll want to remove from your release mode scripts.

JIT’d JavaScript is all the rage and Microsoft dropped the ball again

2009-01-11T04:09:00Z

There’s a lot of buzz lately about browsers finally getting JIT’d JavaScript. First it was SquirrelFish in WebKit, then FireFox let the cat out of the bag about their implementation called TraceMonkey and then Google came out with V8 when they unleashed Chrome on the world. Kudos to all of those teams for pushing performance forward since DHTML/AJAX apps these days are really starting to show the signs of weakness in current JavaScript engine implementations. Now’s when I turn this into a rant on how Microsoft dropped the ball again…

Let’s be honest, Microsoft held the crown for quite some time with their ActiveScripting engine. It was a pretty damn good implementation considering it was created in 1996 and only recently did they actually start to care about its performance again. Microsoft has had a .NET based JavaScript engine since .NET 1.0 (announced in 2000, released in Feb. 2002) which runs on the CLR and, as a result, has spanked the crap out of the ActiveScripting engine since day one. Now, granted, IE6 was released in 2001, so there’s pretty much no way it could have been in there, but… why the heck didn’t they switch to it in IE7? They could have been ahead of the curve and probably still hold a performance crown against these other implementations (or at least come close). Better yet, why didn’t they at least switch to that in IE8?!? In fact, let’s take it one step further! More recently, as work for the Silverlight 2.1 platform, Microsoft has moved ahead with the Dynamic Language Runtime (DLR) initiative and they’ve provided an entirely new, cross platform implementation of the CLR and a DLR flavor of JavaScript which is probably even more efficient. So, even better, why didn’t IE8 build on that? Why didn’t IE8 just take the dependency on Silverlight 2.0 which is a freakin’ ~2meg add-on which at least 1/3 of which is probably made up for by removing ActiveScript. Not only that, but it would help increase the surface area of Silverlight. Can you say “win, win”? I knew you could.

I’ve worked with Microsoft technology my entire career and I’ve seen the various departments blow integration opportunities so many times I’m really starting to get sick of it. At least the newer projects within Microsoft seem to be doing a better job, so perhaps they’ve finally got some architects in there that are actually taking in the bigger picture and doing a lot more cross pollination, but man to see IE8 blow it again just makes me shake my head. Between keeping the antique ActiveScripting engine and writing yet another version of a rendering engine that is pretty much redoing everything WPF does with no where near the extensibility or features, I just gotta wonder what that team is thinking. They must have a serious case of “not invented here” syndrome and like writing/maintaining a bunch of plumbing code rather than being able to focus on higher level HTML/CSS specific stuff or spending more time building better browser features. *sigh*

Velocity Cache API needs TryGetValue

2009-01-10T19:29:04Z

Ok, I’ve just started working with Microsoft’s Distributed Caching API (aka “Velocity”) and while I’m very happy with the features thus far (can’t wait for notifications!), I really think the API needs a TryGetValue method. Right now you have the Get, GetAndLock and GetIfNewer methods and all of those return type Object. My suggestion is two-fold:

Add the TryGetValue method with similar overloads to Get. Return a bool which, if true, indicates the item was found.
Take it a step further and make the method generic. This will help when working with simple value types like DateTime, Int32, Guid, etc.

Imagine you’re caching a DateTime and want to look it up… here’s an example of how you need to do that with the API today:

object cacheValue = cache.Get(“MyCachedDateTime”); DateTime myDateTime; if(cacheValue != null) { myDateTime = (DateTime)cacheValue; } else { myDateTime = CalculateSomeComplicatedDateTime();

cache.Add(“MyCachedDateTime”, myDateTime);
}

// … use myDateTime here …

Notice the annoying need to have a temporary object variable (“cacheValue” in the sample). You need that because you can’t cast straight to a value type like DateTime. Now let’s look at what it might look like with the TryGetValue implementation I’m suggestion:

DateTime myDateTime; if(!cache.TryGetValue<DateTime>(“MyCachedDateTime”, out myDateTime)) { myDateTime = CalculateSomeComplicatedDateTime(); cache.Add(“MyCachedDateTime”, myDateTime); } // … use myDateTime here …

There’s no denying the second version results in less code and, IMHO, this pattern is far more legible.

ScriptReferences to ScriptResource.axd for GAC’d assemblies are problematic in server farms

2008-07-29T12:20:46Z

Ok, I just discovered a nasty little problem with ScriptReferences to script files that are embedded in assemblies that are installed in the GAC… starting with System.Web.Extensions itself.

First, in case you’re not already familiar with this subject, the way scripts are referenced when they are embedded into assemblies is by building a URL to the ScriptResource.axd handler that is provided by the ASP.NET AJAX server side runtime. The URL that is build includes two query string parameters:

“d” – this is a encoded/hashed copy of the assembly identity that includes it’s typical .NET assembly identity info (name, version info, etc.)
“t” – this is a timestamp parameter that is taken from the assembly’s last modified date in terms of the file system.

Second it’s important to realize that when assemblies are placed into the GAC they actually receive a new last modified time on the copy of the assembly that is put into %SYSTEMROOT%\Assembly. This is news to me personally, but then again it never mattered before because the times on those files never mattered in the traditional .NET application. So, if you’re installing a GAC based assembly on multiple servers in a web farm, there’s virtually no way that the last modified time on the assembly on one server will end up matching the time on the other servers… unless you were using a virtual server image of course.

So, with those two details out there, I’m sure you already see the problem: the “t” parameter will be emitted differently from each server in your farm resulting in different URLs.

So why is this a problem? Well your end users hit www.foobar.com and ServerA fields the first request. ServerA’s ScriptReference to Microsoft.Ajax.js serves up a ScriptResource.axd URL with a t=1234 (just an example). Now the user does something that requires a new page to be served up and that request ends up going to ServerB. Well ServerB’s ScriptReference to Microsoft.Ajax.js ends up serving up a ScriptResource.axd URL of t=5678 and guess what? Yup, the user has to download that rather large script file all over again because as far was their browser knows the URL is different so the content must be different.

That’s the typical problem most people using ASP.NET AJAX will have. Non-runtime, silent, not deadly, but killing performance none-the-less. Another problem you can have if you’re doing more advanced work is if you dynamically load scripts (using the ScriptLoader) the URLs will not match and you’ll potentially end up trying to load the same script twice and you’ll end up with a runtime error.

This may not seem all that significant, but consider that it will happen for every script that is served out of a GAC based assembly you reference in your web project. Depending on how large those files are and how many servers you have in your farm you may be causing your end users quite a bit of network load/startup time.

<rant>
IMHO, the inclusion of the “t” query string parameter flies in the face of the power of .NET assembly identity. They’ve taken a well defined, working system which was already being leveraged for the “d” parameter and completely broke it by including another piece of information to identify the assembly. The only plausible explanation for the “t” parameter is that they want to support the “lesser” developers out there who aren’t incrementing their assembly version numbers correctly or maybe has to do with the “pure” web project style projects (which I never use personally, always use web application projects), but I’d be willing to bet they don’t even have any version information by default.
</rant>

So how can you solve this problem? Well there’s several ways that I can think of, none of them great:

You can move to host your GAC’d scripts using the file system, but this completely circumvents the entire benefit of having them in the assembly in the first place.
Handle the ScriptManager.ResolveScriptReference event and write the script paths yourself without the “t” parameter. The problem with this approach is that if you wanted to build links to ScriptResource.axd you’re up the creek without a paddle because all of the methods associated with building these URLs are marked as “internal” within the System.Web.Extensions assembly.
You can choose to “Copy Local” the GAC based assemblies in your build, but this really defeats the purpose of assemblies being installed in the GAC in the first place and has farther reaching implications for your applications.
You can manually go and set the last modified time on those assembly files in the GAC across all your servers using a script of some kind.

We’ve opted for #4 here at Mimeo. We’re using a PowerShell script to set the FileInfo::LastWriteTime on the GAC based assemblies to a fixed date for all the servers. It’s a hack, sure, but at least it’s a server configuration hack and not a runtime hack.

Finally, I have submitted a bug to the connect.microsoft.com site about this problem. Please go and vote on it if you feel it’s as important as I do.

ADO.NET Entity Framework's CompiledQuery when using anonymous projections shows why C# needs "mumble" types

2008-05-15T12:28:35Z

Ok, that's a really long title for a post, so what the heck do I mean by all that? Well, I've started working with the CompiledQuery class and I've run into a language limitation problem that almost makes any kind of performance gain I might get from CompiledQuery not worthwhile when using projections due to the fact that they cannot be anonymous so you're forced to define a new class yourself to represent the projection.

First off, if you're not familiar with CompiledQuery, it's basically an optimization provided by the ADO.NET Entity Framework that enables it to take your LINQ expression once, generate a cached execution plan (not in the SQL sense, but in the entity sense) for it and return you a Func delegate on the fly that takes parameters to allow you to plug in any dynamic values you might need for the query (e.g. for a where clause).

Secondly, if you're not familiar with the C# "mumble" type problem, jump on over to this excellent post from Ian Griffiths where he details the issues quite well and even talks about the language changes that the C# team was thinking about making to support the concept.

Go ahead... I'll wait. Done yet? K. :) So here's why CompiledQuery suffers from this problem annoying problem. The whole point of CompiledQuery is that you can call Compile once for the LINQ expression and store the resulting Func delegate instance so you can reuse it over and over. So ideally you'd want to store this Func delegate in a static variable or, at bare minimum, a member variable right? Here's how you could create a compiled query that allows you to find all orders for a customer in a specific status. Note that for my examples, I'm assuming we've created an EF model over the AdventureWorksLT DB.

public static Func<AdventureWorksLTEntities, DateTime, IQueryable<SalesOrderHeader>> GetCustomersOrdersByStatus = CompiledQuery.Compile((AdventureWorksLTEntities entities, int customerId, int status) => from order in entities.SalesOrderHeader where order.CustomerID == customerId && order.Status == status select order);

I can then call this function and consume it's results like so:

using(AdventureWorksLTEntities entities = new AdventureWorksLTEntities()){ foreach(var order in MyCompiledQueries.GetCustomersOrdersByStatus(entities, someCustomerId, someStatusValue)) { /* ... do something with the order ... */ }}

Now, the above example actually works out just fine because we're selecting the entire SalesOrderHeader entity type so I know the type parameter for my IQueryable<T> is going to be SalesOrderHeader. The problem comes in when you want to do a projection of fields, either from multiple entities or just reducing the number of fields you bring back from a single entity because that results in an anonymous type being generated. For example, assume I want to bring back some data from the customer and just some data from the order for presentation in a list view:

public static Func<AdventureWorksLTEntities, int, int, IQueryable<???>> GetCustomersOrdersByStatus = CompiledQuery.Compile((AdventureWorksLTEntities entities, int customerId, int status) => from order in entities.SalesOrderHeader join customer in entities.Customer on order.CustomerId = customer.CustomerId where customer.CustomerID == customerId && order.Status == status select new { CustomerId = customer.CustomerID, CustomerFirstName = customer.FirstName, CustomerLastName =customer.LastName, CustomerCompanyName = customer.CompanyName, OrderSalesOrderId = order.SalesOrderId, OrderDate = order.OrderDate, OrderTotalDue = order.TotalDue });

So, as you can see, I'm now trying to project an anonymous type that is composed of values from two separate entity types. The problem is not the LINQ query because it works just fine by itself. The problem is that I can't determine the type parameter type for the IQueryable<T> for the result parameter of my Func variable because that type is anonymous. This is where having the ability to use a "mumble" type and say IQueryable<var> would help out tremendously because the compiler does know the anonymous type.

The only solution to this problem today AFAICT is that you actually need to declare a class to represent the projection and use it to type the Func signature and select it instead of an anonymous type in the LINQ query:

public sealed class CustomerOrder { public int CustomerId { get; set; }

/* ... declare other properties here ... */ } public static Func<AdventureWorksLTEntities, int, int, IQueryable<CustomerOrder>> GetCustomersOrdersByStatus = CompiledQuery.Compile((AdventureWorksLTEntities entities, int customerId, int status) => from order in entities.SalesOrderHeader join customer in entities.Customer on order.CustomerId = customer.CustomerId where order.CustomerID == customerId && order.OrderDate == orderDate select new CustomerOrder { CustomerId = customer.CustomerID, CustomerFirstName = customer.FirstName, CustomerLastName =customer.LastName, CustomerCompanyName = customer.CompanyName, OrderSalesOrderId = order.SalesOrderId, OrderDate = order.OrderDate, OrderTotalDue = order.TotalDue });

And so depending on how large your projection is this forces you to do a hell of a lot of code generation which as of today is very manual. It would be great to have a tool that could generate a strong type based on the anonymous type syntax. Maybe there's one out there today that I don't know about?

Anyway, it's still all stuff the compiler should be smart enough to do for you. The annoying thing is it already does this work, but it's limited to local scope only. Perhaps another solution would be that, instead of using the var keyword to "mumble", they actually gave us a way to give the anonymous type a name inline which would basically name the anonymous type instead of the compiler just generating a random type name.

David Teitlebaum on Channel 9 reviewing WPF 3.5 SP1 features

2008-05-13T08:48:11Z

It's WPF week over on Channel 9 and a new episode went up yesterday which has David Teitlebaum, a PM on the WPF team, giving an overview and demos of the new lower level features that SP1 brings to the table. You don't want to miss it, so hop on over and check that out.

I think we all know the Effects stuff is the most sought after feature, but I know a lot of people were looking for the WriteableBitmap feature since WPF 3.0 and now they have it and, judging by the demo, the performance is amazing.

Greg Schechter begins series on WPF Effects

2008-05-12T13:50:21Z

Greg Schechter has begun a series that covers the ins and outs of the new effects API in WPF 3.5 SP1 (3.6??). This is the real effects API we in the WPF community all been waiting for. It's completely GPU based and unlocks an infinite amount of potential for WPF designers.