What you see in Working Set of SQL Server 2008 process (sqlservr.exe) is NOT amount of memory allocated by the process

Here is some extended info.

Technorati Tags: SQL 2008,AWE,Task Manager,Working Set

Practical tutorial on using Sgen.exe to improve performance of XML serialization startup.

There is an overhead incurred when using serialization in your application, which is caused by generation of a ‘helper’ assembly for each type that is serialized with XmlSerializer (per-process-per-domain). (Btw – this has subtle adverse effect – if you use serialization – your application should have Read/Write permissions to %windir%\temp folder).

This overhead may be avoided by using Sgen.exe tool to pre-generate serialization assemblies.
Basically it should be pretty straightforward, especially if your FooBar.dll assembly for which you pre-generating serialization assembly doesn’t has a lot of references. Unfortunately – if you do have a lot of references – you would have to add them all using /reference:c:\foo1\foo1.dll /reference:c:\foo2\foo2.dll /reference:c:\foo3\foo3.dll ……

Here is a workaround:
To generate serialization assembly manually (could be done as a post-build step):
1) Visual Studio –> Foo.csproj –> Properties –> Build –> Generate Serialization Assembly –> On
You would expect it to work automatically now – but it wouldn’t, or saying it more precisely it would create serialization assembly only if your assembly includes proxy types (e.g. web-services).
Anyway – build your assembly, open MSVC output window and look for sgen.exe line in the end of output.
2) Copy whole sgen.exe line – it would include all the references needed.
3) Remove from it /proxytypes parameter – this will cause sgen.exe to generate serializers for regular types.
4) Add /force parameter to force overwrite of previously created assembly.

Now you almost done except of following caveats:
1) If you have types with the same name in different namespaces you would get error saying something like:
Error: There was an error reflecting type ‘FooNamespace.Foo’ – Types ‘FooNamespace1.Foo’ and ‘FooNamespace2.Foo’ both use the XML type name. Use XML attributes to specify a unique XML name and/or namespace for the type.
To resolve it – differentiate your types by specifying XML namespace:

   1:  using System.Xml.Serialization;

   2:   

   3:  [XmlType(Namespace = "urn:Foo1")]

   4:  [XmlRoot(Namespace = "urn:Foo1")]

   5:  public class Foo{}

2)  If you have properties with readonly or internal properties, or internal types – you would get the following error:


Error … property or indexer cannot be assigned to it is read only.

You may either mark such property with [XmlIgnore] attribute or (for internal) – add following line to AssemblyInfo.cs file:

[assembly: InternalsVisibleTo("<AssemblyName>.XmlSerializers, PublicKeyToken=null")]

You may still add it as part of build process manually modifying MSBUILD script in .csproj file.


Look here or here for details.

Technorati Tags: C#,.NET,Sgen.exe

How to activate Fusion logs

Technorati Tags: .NET

Fusion.reg file:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion] "LogPath"="C:\\FusionLogs" "ForceLog"=dword:00000001

How productivity changes throughout the weekdays

Graph below shows distribution of my blog visitors throughout the weekdays (this picture depicts a specific week, but the pattern is consistent over the time.
Since my blog is mostly devoted to the technical issues I think it could be a measure of common productivity pattern throughout the week.

So:

1. It seems that proverb saying “Monday is a holiday” looks to be statistically right.
2. Well, actually it seems it talks about the Tuesday as well …
3. Wednesday and Thursday are most productive days, Thursday is a bit better.
4. Friday is in much better than Tuesday but shows clear decline to Thursday.

Insiders sell like there's no tomorrow …

Performance of Velocity distributed cache

I was looking for some numbers on performance and throughput of Velocity. First of all here is some extensive performance data from Microsoft Velocity team blog: http://blogs.msdn.com/velocity/archive/2009/04/21/more-performance-numbers.aspx My own test (single cache node, single client on a neighbor LAN computer - sequentially storing 100 .. 1000 instances of the same data into the cache) shown time of around 14-18 ms (per chunk) when storing data chunks of 100K up to 1Mb.

The requested upgrade is not supported by

Proxy should be updated...