Super Krazy Microsoft Week, blated

I meant to have a nice summary of both the Developer Days training which I attended and the meeting I had with fellow DotNetDevelopers about forming an Ann Arbor group.

I didn’t get around to it 🙂

Basically ADO.NET 2 has some awesome features.  DataTable is a first class citizen now, so you can use it directly without the overhead of a DataSet.  Asyncronous stuff is awesome.  SQL Server 2005’s XML features are REALLY VERY SWEET.  Finally, the CLR in SQL Server is nice, but I fear it will be abused rather than used well.

As for the new Ann Arbor Dot Net Developers (AADND), well, I love the that DND could also mean Dungeons ‘n Dragons.  It makes me laugh.  We are meeting the second Wednesday of every month at the Ann Arbor IT Zone.  There is a great group of people helping to get this organized.  I don’t recall everyones names, but Josh Holmes nudged me to volonteer for something, so I’m into advocacy.  I’m calling people I haven’t talked to in years and asking them to come to our meetings.  Well, OK, no I’m not.  I’ve only lived in Ann Arbor for about a year and a half.  But I’m doing my best to invite any programmers and tech savy people I know.

Did I mention that the meetings are The Second Wednesday of every month at 6pm?

The Ann Arbor IT Zone Launch Pad is located at:

330 E. Liberty
Ann Arbor, MI 48104

Our meeting format is such that we have a basic tutorial presentation at 9pm that should be understandable by anyone with basic programming background.  It lasts about 45 minutes and we get pizza and chat and then watch the main presentation which is on a more specific topic.

At our February 8th meeting, I’m giving the first tutorial, an overview of ASP.NET.  Then Josh Holmes is presenting something that is more detailed in ASP.NET.  I don’t recall exactly what, but I’m sure it will be excellent.

Super Krazy Microsoft Week, Day 1

Ok, this is super krazy Microsoft week for me. Today is day 1.

Today was the MIGANGmeeting. The rest of my super krazy Microsoft week involves free training on Friday afternoon and meeting to setup an Ann Arbor Dot Net Users Group on Friday evening. I’ll be doing penance for weeks to come by using only Linux.

MIGANG’s format is that there is a tutorial at 6pm, followed by eats and a more advanced presentation at 7pm. Today was a little different. The tutorial was a solicitation about NPower Michigan and the possibility of collaborating on projects with them. NPower helps non profits put technology to use. Sometimes custom programmed solutions are required and most of the time non profits simply cannot afford to contract a developer to do them. MIGANG is going to contribute the programming effort on a volunteer basis. This is REALLY COOL. I have no idea why more groups aren’t doing things like this, and by more groups I certainly don’t mean dot net groups. I more mean the Linux groups and they Python groups and so on. Open Source philosophies just seem to match with non profits, but that is just my view.

The 7pm presentation was on NGEN and Rebasing to improve application load times. (Charles) Stacy Harris presented.(The Charles is silent). Now I haven’t been to many MIGANG meetings. I have been to two. They were November 2004, which turned out to be a special event, the .NET Mobility Roadshow, and December 2004, which was a normal meeting with an INETA speaker. It was interesting, but not immediately applicable for me. The topic was something about advanced Web Services this or that. Today’s presentation seemed different; I guess it was the topic.

Stacy says that Claudio Caldato has an article in MSDN magazine this month on the same topic. Poor Stacy had his thunder stolen. 🙂

Stacy started off and I felt like I was back in my undergraduate operating systems course. He drew on the whiteboard the memory space of a process and show the heap and stack and mentioned shared libraries between process and the virtual vs. physical address space. I felt right at home. Then he went into how DLLs are loaded by the loader. It turns out that the Windows developer tools default all DLLs to have the same base address. The loader loads the dll and has to rebase (relocate for you UNIX and Linux people) the library to an available location in the process’s virtual address space. I wasn’t immediately sure that rebasing was the same as relocating, but upon getting home I did some background reading and it is indeed the same. The Windows developer tools (somewhere) includes a tool called rebase which will let you change this base address of this DLL and all the offsets within it.

At the time of presentation I was fuzzy about how exactly prelink works in Linux. It turns out I had it wrong as I was trying to remember it; I thought it was somehow related. Nope. It is not related, it IS the same thing. What Linux (and presumably other ELF based operating systems) calls prelinking, Microsoft calls rebasing.

There is an interesting point with respect to rebasing when talking about managed code. This point probably applies to Mono DLLs as well. In the case of a signed assembly, the signature for the signed assembly will no longer be valid after rebasing(prelinking). Go read how assembly signing works if you want to know why. So I guess it is best to set the library offset address at compile time before signing and then sign that assembly.

Inspection of the address space for a process can be done via command line using a Microsoft tool called vadump or better yet with a nice GUI tool from sysinternals.com calls Process Explorer (which does a lot more too). These tools also show the libraries default (suggested) base address as well as where it ended up in the process. This must be the kind of output which prelink uses when it forks ld to obtain its library offset information.

Of course the presentation was not just on prelinking (ugh, rebasing). Another optimization was use of the MultiDomain loader optimization. This makes the compiler generate reentrant assemblies, so that they are only loaded once in the process but can be used by more than one app domain. No one could say for sure why this is not the default. I’ve got one program which uses multiple app domains, so I may explore this option for optimization.

Also mentioned was a brief discussion on JITTING vs. NGEN and pros and cons. I didn’t get a sense that it was a preferred optimization. It(NGENing) may help application performance, but it has its cons. I definitely wasn’t clear on how it effected load times, but it is definitely something to investigate if you are having performance issues. This debate seems to be quite popular on blogs and forums so google for ngen and I’m sure you will find some lively discussions.

Another load time optimization had to do with the security of signed assemblies. The use case throughout the presentation was a program which loaded close to 300 DLLs, all at program startup. I’m not sure this next optimization would really make a different for most programs. When loading a signed DLL, the first thing the loader does is validate the hash. This is expensive. When an assembly is in the GAC, the hash is validated at GAC install time. Assemblies loaded in the GAC don’t need to be validated. The possibility of a security problem was suggested. Happy cracking.

Another optimization which is not limited to program or library load time was the last one mentioned and the only one which I’ve actually run into. The example given was allocating a large (even just 1M) byte array in a multi-threaded(or not) situation which can lead to lots of allocations on the heap and lots of garbage collection as the allocated objects go out of scope. The solutions suggested were what one programmer did was what ended up being writing their own memory manager. It turns out that C# in unsafe mode allows stack allocation. That is the solution they used. Stacy really liked the idea of writing that bit of code in managed C++, but the project leaders or someone with authority didn’t agree. It turns out they used stackalloc to solve it.

I ran into exactly the same issue on a single threaded very simple for loop where for some foolish reason I was not paying attention and I was doing a bunch of heap allocations for every cycle of the loop. It was fun to connect to the process with Performance Monitor and watch the allocations and garbage collections use 90% of my CPU leaving only 10% for my program to actually run. That was when I started to understand what Scott Collins had said to me a while before about good program architecture. I knew what he meant at the time, but now it was really sinking in.

In all it was a very impressive topic. I really enjoyed it.

I ran home and skimmed a linux prelink paper (ftp://people.redhat.com/jakub/prelink/prelink.pdfto refresh my knowledge and now I realize that I really got a presentation on how it work in Microsoft land.

New Enterprise Library Data Access Application Block looks a lot like Mono.Data.ProviderFactory

The new Enterprise Library Data Access Application Block (Oh my gawd that is a mouthfull) uses some other part of Enterprise Library 2.0 called IConfigurationSource. This is pretty cool, but the DAAB (because Data Access Application Block is such wordy) bit of it looks an aweful lot like Mono.Data.ProviderFactory.

http://codebetter.com/blogs/david.hayden/archive/2006/01/08/136360.aspx

http://little.xmtp.net/blog/2005/11/22/more-proper-data-abstractions-in-net-and-mono-applications/

AACS and AAPUG

Last night was a meeting with Ann Arbor Computer Society where I got to witness some interesting demo of .NET CF 2.0 databinding. That was interesting, but the real good part about the meeting was the community and coming together and open discussion of ideas. One thing that I found the most unique right away was the openness of people regardless of their respective software systems. Windows, Linux and MacOS alike all came together to share information.

Tonight I just got back from an MichiPUG meeting. Where PUG means Python Users Group. I got to sit in on a very detailed TurboGears presentation and discussion. I know python well enough to follow anything, but I’ve never used TurboGears. This presentation didn’t start anywhere, it just dove right into “what’s new”. I get the impression that the regulars have been together for quite some time. They all tend to be familiar with TurboGears. The was the first time I’ve been to a UG meeting of any kind where it seemed like everyone in attendence was REALLY deep into the subject matter. Often times at LUG meeting, members don’t have a deep knowledge of what they are talking about and there are a few gems in the rough. This seemed to be the exact opposite at the MichiPug meeting. I was impressed with the comments of everyone who contributed to the conversation. It was very refreshing.

So I’ve been in a bit of a rut as far as developing anything outside of the workplace. I think I’ll need to try TurboGears for something. The widgets concept are a huge welcome addition to an open source web framework. I think they are much like the concept of ASP.NET controls or maybe JSP tags, but they are of course Python. I’ll try to clarify that as I learn the TurboGears framework. I welcome anyone who is learning python (whiprush) to come out to the Michipug meeting next month. Meetings are on the first Thursdays of the Month.