.NET Memory Usage in 64-bit

Posted on by
Reply

In a meeting the other day one of my colleagues mentioned we might need to move one of our applications to 64-bit, mainly because it was memory bound and was restricting the number of threads. Incase you don’t know, .NET 32 applications are restricted to 2GB, whereas (atleast I believed) 64-bit applications aren’t under the same limitation (atleast in terms of total memory usage).

However another colleague came out and said that 64-bit .NET is restricted to only using 4GB of memory, which made no sense to me whatsoever, knowing that .NET is used on servers all over the world and a limitation like this would make it laughable for a server app. Rather than arguing the point based what other people say (and being abit of a pragmatist) I decided to right then and there write a little test:

        static void Main()
        {
            var list = new List<int[]>();
            while (true)
            {
                try
                {
                    list.Add(new int[1024]);
                }
                catch (OutOfMemoryException)
                {
                    Thread.Sleep(1000);
                }
            }
        }

 

Simple? Yes,

Is it crude? Yes

Does it cause most applications (including Visual Studio itself) to freeze/become unresponsive when it is run? Yes.

But when you run it, it will use up all RAM available on a machine (unless you have so much RAM that you actually manage to add more elements to list than it can contain, in which case you must be reading this from a bunker or 10-15 years in the future). Which is all the evidence you need.

This should go without saying since I have already mentioned that this code is not exactly safe, but I take no responsibility for anything that happens when using it. I mean seriously, it’s an application that aggressively takes all available resources and never frees them, of course it is only going to cause you problems when you run it.

Simon vs OSX: Round 2

Posted on by
Reply

I couldn’t find my IDE DVD drive, but I found my old faithful USB DVD drive and gave it a go.

The Almighty OSX Install Screen of Power

Apparently this is much further than most people get, going by the near on millions of posts across the web complaining about the “still waiting for root device” problem.

All that remains is to canibalise the IDE HDD from one of my old machines to install OSX onto. If you’re wondering why, it’s basically because there are no SATA drivers on a Mac for my motherboard (since they don’t sell Macs on the nForce chipset). As a result I can’t use any SATA devices (atleast until I can install OSX and can install drivers for it).

So on the plus side I can install OSX, on the downside it has to sit on it’s own IDE drive.

So I call this a draw.

Saving a Xaml FlowDocument to a Jpg

Posted on by
Reply

Yeah, this might be a little specialised, but there is a reason. In some code I’ve inherited that prints a file out to a printer, now needs to support printing to both a Jpg as well. Now the there is plenty of information around about saving Xaml to Jpg but an awful lot of them don’t work fully.

var flowDocument = (FlowDocument)System.Windows.Markup.XamlReader.Load(xmlReader);

var page = flowDocument.DocumentPaginator.GetPage(0);

var bounds = VisualTreeHelper.GetDescendantBounds(page.Visual);
var renderTargetBitmap = new RenderTargetBitmap((int) (bounds.Width),
                                                (int) (bounds.Height),
                                                96.0,
                                                96.0,
                                                PixelFormats.Pbgra32);
var dv = new DrawingVisual();
using (var ctx = dv.RenderOpen())
{
    var vb = new VisualBrush(page.Visual);
    ctx.DrawRectangle(Brushes.White, null, new Rect(new Point(), bounds.Size));
    ctx.DrawRectangle(vb, null, new Rect(new Point(), bounds.Size));
}

renderTargetBitmap.Render(dv);

using (var fileStream = new FileStream(@"C:\testimage.jpg", FileMode.Create))
{
    var bitmapEncoder = new JpegBitmapEncoder();
    bitmapEncoder.Frames.Add(BitmapFrame.Create(renderTargetBitmap));
    bitmapEncoder.Save(fileStream);
}

The main thing to note about using this method is that the image will default to black, so if your FlowDocument has more than just images (which will be the case for most FlowDocuments), you’ll get a strange looking image like this:

This is reason for the line ctx.DrawRectangle(Brushes.White, null, new Rect(new Point(), bounds.Size));

This line fills in the background with white, if you wanted a more generic solution, if you’re FlowDocuments aren’t always on white backgrounds (which they may not always be), you could grab the colour from the FlowDocument background property. It does make me wonder why it doesn’t render the background colour onto the image to start with but since it’s no doubt mapped down to an unmanaged function it’s probably some kind of optimization or something like that.

HTC Desire with Android 2.2

Posted on by
Reply

Yes, T-Mobile UK finally got around to releasing Android 2.2 for the HTC Desire, and I have just upgraded.

What’s it like? Well if you own a newish non-HTC android phone, or even a unlocked HTC one then you’ll probably be suprized that I’ve only just got it (probably about as suprized as I was to learn that the Dell Streak has only just got 2.1). Well for anyone else: you can finally install apps to the the SD card. Which is pretty awesome to coincide with the release of the MonoDroid preview (which I am privileged enough to be part of) and also the release of the Windows Phone 7 SDK. But now we’ve move away from the Android and over to .NET.

New features include:

  • Apps to SD
  • Performance increases
  • Wifi Tethering

Straight away it does appear to be faster, which is saying something since it already really responsive before anyway.

Also, if you’re wondering why I missed so much functionality off that list, the fact is that alot of the functionality was already availably for the HTC variety of phones anyway (such as Adobe Flash support, Improved Exchange support, USB tethering, etc) but the WIFI tethering is a nice addition, something I lost due to not rooting my phone this time around (due to the problems I had last time).

Having just tried google goggles (one of the apps that makes all my iPhone loving friends turn green with envy), it is insane how much better it is than before. it seems to be almost instant now. On top of that I scanned a can of Iron Bru (I like Iron Bru) and it fought both the Iron Bru logo and the Bar (people that make Iron Bru to anyone that doesn’t know what I’m talking about) as well. Prepare to see some people turning green within the coming weeks.

.NET Message Logger using some advanced stuff

Posted on by
Reply

I’ve recently been delving into the logging stuff used in the project I’m working on, and well the basic format for a log seems to be: [Date] : [Method] [Class] [Type] [Message] . And that’s a fairly reasonable way of logging stuff I guess. But because the people who wrote it probably didn’t plan the system ahead of time, maybe mixed with not knowing about some the System.Diagnostics stuff that is around and has been around for a long time already, as such we get code along the lines of:

log.Info(string.Format("{0} {1} {2} {3}", DateTime.Now, MethodBase.GetCurrentMethod().Name, this.GetType().Name, "message"));
log.Serious(string.Format("{0} {1} {2} {3}", DateTime.Now, MethodBase.GetCurrentMethod().Name, this.GetType().Name, "message"));

And there’s literally code like that written often several times in each method. This makes me a sad panda since there are several ways they could have avoid such a large volume code. This also makes everything look messier than it it should be. As a result I have written a somewhat bare bones alternative that largely does the same thing, but which much less code.

The first tool in my arsenal: System.Diagnostics.StackTrace. Now most people I know about stack trace, most often people use it output the trace upto when an exception was thrown (infact by default Exceptions store the current StackTrace for exactly this purpose. However, are other functions that can be taken advantage of. For example, If you want to get the method that method that called the currently calling method you could do the following:

var stackTrace = new StackTrace(true);
var method = stackTrace.GetFrame(1).GetMethod();

If you don’t know what this code is doing, here is the simple explanation. The true in the constructor gets source information, in this example I’m only going to be using that for getting the line number of the source code that the message occurred on. After that the stackTrace.GetFrame(1) method pulls out the stack frame above the current one (0 would pull out the current StackFrame, so would give you the information about currently executing code). The GetMethod() method returns the method as an instance of MethodBase, giving you access to information about the method without needing to collect this information at the time.

Anyway, here is the code:

Sample Code

Working

Posted on by
Reply

Currently under employment for Halse at a top secret location… in just outside Reigate.

While on the job I have had a great idea for an open source project… it is all top secret, but watch this space.