As some of you may know last July I have requested the Monbukagakusho (MEXT) scholarship to go to Japan for two years, to do research at Kitsuregawa Lab at Tokyo University. As I wrote earlier, I had already passed the preliminary selection in August last year, and had been accepted into Tokyo University shortly after. The only thing I was still waiting for was the final approval from the Japanese government that I would get the scholarship.
That approval has not yet officially arrived, however a recent e-mail from Tokyo University implied that they believed I had been accepted, which prompted me to call the Japanese Embassy, who called MEXT in Japan, and told me that it was true: I've got the scholarship!
The paperwork isn't done yet, which is why neither me nor the Embassy had been informed yet, but it is official. Next April I will fly to Tokyo, Japan, where I will stay for two years. I can hardly believe that it is really happening, but it is!
You will believe I'm more than a little elated about this! Finally I have certainty after months of waiting!
Because the paperwork isn't finished, I don't have all the details yet. For instance, although I know I'll be leaving in the first week of April, I don't yet know the date or other flight details. I also don't know precisely where in Tokyo I will live, although it's likely I will end up in an international house (special housing for international students), one of which is on the same campus as Kitsuregawa Lab, so that would be very convenient.
Of course, this blog is the place where I will keep all those who are interested up to date on all this. In fact, the possibility that I would be going to Japan was one of the main reasons why I started a blog in the first place.
Now however comes the really hard part. I have to focus on my work for the remainder on the day while what I really want to do is stand on the roof and shout it: I'm going to Japan!
Okay, they're for work, so they're technically not toys and they're also not actually mine, but this is still neat.
As some of you might know, the one thing that was still noticably absent from my desk at University was a PC. I had to use my own (old, slow) laptop to do my work, not exactly ideal.
Now, I finally got a PC. And quite a nice one it is too; quite a bit faster than the one I have at home. It's got an Intel Core 2 Duo 6600 (2.4GHz) CPU, 2GB DDR2 667MHz RAM, an nVidia GeForce 7950GT with 512MB RAM and two 250GB SATA hard disks. It far exceeds what I actually need, but you don't hear me complaining. :)
Perhaps the most amazing piece of equipment however is the monitor. It's a Samsung 225BW 22" widescreen LCD panel:
It's huge! The picture just doesn't convey how big it truly is. Working with it is like sitting front row in a cinema. I realize this may be old hat for a lot of people, but it's the biggest monitor I've ever worked with. When I came home today I couldn't help but think how small my own 17" CRT really is. :P
And it appears a fairly decent monitor in other aspects as well (especially considering its price). Response time is great, and colour clarity is good; definitely more than adequate for what I'm going to be using it for. The only drawback is that at 1680x1050 I think its native resolution is on the low side for a monitor this size. A bit higher, like 1920x1200, would've come a long way. But, I suppose that would've made it more expensive.
You may notice I'm running Vista on it. Unfortunately this is not because Leiden University is so up to date with their OS support: it's because due to a miscommunication they didn't have any Windows CD and key for me yet, so I temporarily used my own Vista DVD, installing it without a key (so it's not activated). In a few days I should get the proper XP CD and it'll be bye-bye to Vista. A shame, really, since this kind of machine is what Vista's made of, and not surprisingly it runs beautifully on it.
For the code I'm writing for my job I need to set a lot of properties based on values read from external files. Not only the values are dynamic, so are the property names. To prevent this turning into a giant switch statement that needs to be updated every time I add a property, I wanted to use reflection.
Of course, I've often heard that reflection is slow, and this property setting operation will be done a lot. But, I'm also a big proponent of preventing premature optimization, so I decided to build a simple test, where I pitted reflection against using a dynamically generated method, using .Net 2.0's supercool DynamicMethod class which allows for light-weight code generation. Below is the code I used for this test:
using System; using System.Collections.Generic; using System.Text; using System.Reflection.Emit; using System.Reflection; using System.Diagnostics; namespace DynamicMethodTest { class Foo { private string _bar; public string Bar { get { return _bar; } set { _bar = value; } } } class Program { delegate void TestDelegate(Foo arg); static void Main(string[] args) { TestDelegate test = CreateMethod(); Stopwatch s = new Stopwatch(); Foo f = new Foo(); s.Start(); for( int x = 0; x < 1000000; ++x ) test(f); s.Stop(); Console.WriteLine("Dynamic method: {0}", s.Elapsed); s.Reset(); Type t = f.GetType(); PropertyInfo info = t.GetProperty("Bar"); s.Start(); for( int x = 0; x < 1000000; ++x ) { info.SetValue(f, "Hello, World!", null); } s.Stop(); Console.WriteLine("Reflection: {0}", s.Elapsed); Console.ReadKey(); } static TestDelegate CreateMethod() { Type[] args = new Type[] { typeof(Foo) }; DynamicMethod method = new DynamicMethod("Test", null, args, typeof(Program)); ILGenerator gen = method.GetILGenerator(); gen.Emit(OpCodes.Ldarg_0); gen.Emit(OpCodes.Ldstr, "Hello, World!"); MethodInfo m = typeof(Foo).GetProperty("Bar").GetSetMethod(); gen.EmitCall(OpCodes.Call, m, null); gen.Emit(OpCodes.Ret); return (TestDelegate)method.CreateDelegate(typeof(TestDelegate)); } } }
And this is the result:
Dynamic method: 00:00:00.0326159
Reflection: 00:00:05.8752216
As you can see, reflection is not just slower, it's orders of magnitude slower! This result far exceeds the speed difference I was expecting. I tried to find something wrong with the benchmark, something that would skew the result, but I cannot find anything at first glance (if anyone sees a problem please let me know).
So it would appear that if you have to do a lot of reflection, taking the time to implement dynamic code generation can really pay off.
It's important not to underestimate the power of DynamicMethod. In my case the configuration file containing the properties to set can change without the application restarting; this means that I will need to recreate the dynamic methods and discard those I don't need anymore. And that's precisely the biggest advantage to DynamicMethod; it's discardable. In .Net 1.1, if you wanted dynamic code generation, you had to generate a complete in-memory assembly, and if you're familiar with the CLR you'll know that assemblies (generated or otherwise) cannot be unloaded. That would mean that to prevent a memory leak I would have to place the generated assembly in a separate AppDomain (which you can unload, also unloading all the assemblies contained in it), with all the hassle and performance implications that entails. Thanks to DynamicMethod, none of that is necessary.
I've just become aware that there's a new article on MSDN that provides a step-by-step guide on building a Browser Helper Object for Internet Explorer. Since I know first hand how hard developing IE extensions can be (although Find As You Type is primarily a toolbar, it also uses a BHO to capture the CTRL-F keypress) it's good to see that MS is at least improving the documentation that is out there.
The article uses ATL, which I personally didn't use. Not that I have anything against ATL; it's just that I'm familiar with COM and prefer to have the least amount of auto-generated code possible. But if you're a fresh C++ programmer who's perhaps transitioning from the .Net world who wants to try his/her hands at developing an IE extension, ATL is an excellent way to hide all the tricky bits of doing COM.
In honour of the upcoming holiday season I decided to resurrect Jamie's Christmas avatars. I also took the opportunity to release a small update to the C9IAC itself (as well as the accompanying template editor).
The biggest improvements are in Vista compatibility (it now uses Segoe UI for the UI font, and it will use the Vista style common file dialogs) and high-DPI compatibility. But there's also other stuff, including some UI updates, a change in the default font for avatar text to Calibri, and some other small stuff.
Go check it out!
Subscribe