User:Brion VIBBER/Mono issues

I've been using Mono for a few internal tools for Wikimedia. Generally I like it but it feels a bit immature yet; if you're writing anything non-trivial it seems you've got a good chance of encountering a few bugs in the runtime and class library.

I have gotten good response from the Mono crew on these; isolating a test case, filing a good bugzilla report (perhaps with a patch!) and poking someone on IRC generally gets the job done in a reasonably timely fashion. The class library is reasonably easy to hack, so I've usually had good luck isolating problems and have often been able to provide a simple patch.

However tracking down bugs in the language environment is kind of a pain; it takes time away from what you're trying to accomplish yourself, and then you have to maintain a patched installation for a couple months until the next release... which you promptly have to patch for yet another bug.

I've also had issues with MonoDevelop, but that's another story. :)

For reference, here are the bugs directly impacting the code I've been working on so far:


Mono bugs that have affected search (fixed in current releases):

Dump processingEdit

Affecting page data dump processor (mostly fixed in SVN, after 1.1.9):

I'm moving the dump processing code from C# to Java for a number of reasons:

  • Distribution
    • I need to provide this tool to end-users to work with dumps with a minimum of fuss. Downloading and installing Mono is a bit of fuss; patching Mono source for runtime bugs and recompiling it, more so. A Java VM is more likely to already be present and to be easy to install.
    • I'd hoped to use mkbundle; it mostly works on Linux, unless you have a different libc version... (d'oh)
    • mkbundle doesn't currently work on Mac OS X or Windows
  • GUI frontend plans
    • Gtk# requires a Gtk+ install, is user-hostile on Mac OS X (X11)
    • SWF is hostile everywhere ;)
    • Don't want to write the GUI three times (SWF, Gtk#, Cocoa#)...
  • Tools
    • Eclipse is a much more powerful and productive environment than MonoDevelop. (Translation: it doesn't crash as much! ;)
    • There's actually a debugger that works in Eclipse+Java...
  • Bugs :(
    • I've hit seven bugs in Mono up there, four of them showstoppers that produce corrupted output on the current Mono release.
    • As a result I've spent many hours fixing Mono instead of working on my own code. It's great that I'm helping the Mono project to become more robust, but it's hurting my ability to deliver working code right now.
    • Discovering runtime bugs halfway through (or after) a 40 gigabyte data dump has meant a lot of delays getting said data dumps out. On my Java port I've so far discovered just one timezone-handling discrepancy between the Sun JDK and GCJ, which doesn't even affect my application once I got my timezone usage done correctly. Hopefully that's all I find. I'd hate to go to the trouble of switching again; to Python this time maybe? ;)

The Java version also seems to run a fair clip faster, but I need to test that again as I was having oddities with background file monitor daemons. If it really is 3x faster that's a neat plus. ;)

(One caveat with Java on GCJ 4.0.1 though is that memory usage is bad; it seems to grow the heap significantly. On the Sun JVM memory usage stays svelte.)