It’s pretty straightforward to do basic benchmarking of a single, self-contained piece of code in .NET. You just make a Stopwatch sandwich (
let sw = Stopwatch.StartNew(); <code goes here>; sw.Stop()), then read off the elapsed time from the Stopwatch.
What about measuring the throughput of a data pipeline? In this case one is less interested in timing a single block of code from start to finish, and more interested in bulk metrics like computations/sec or milliseconds/item. Oftentimes such pipelines are persistent or very long-running, so a useful benchmark would not be a one-time measurement, but rather something that samples repeatedly.
Furthermore, it’s sometimes difficult to determine where the bottleneck in a chain of computations lies. Is the root data source the culprit? Or is it perhaps an intermediate transformation that’s slow, or even the final consumer?
I’ve recently had reason to do a bit of work with JNI . Throughout the course of this work I had to do quite a lot of Googling in order to figure out how to properly manage the caching of various JNI objects used by my C++ code. Some JNI objects can be safely cached and re-used at any point, while others have limited lifetimes and require special handling. Obtaining JNI objects through JNI APIs is, broadly speaking, fairly expensive, so it’s smart to persist those objects which will be re-used in multiple places. You just need to be careful.
I expected to find a big table somewhere that documented the lifetime restrictions (or lack thereof) for each of the JNI object types, but sadly I was unable to locate one. Instead, I wound up trawling through numerous Stack Overflow replies, blogs, forums, and other documentation to obtain this information.
This post is my effort to provide to others the missing quick reference I wish I’d found. I recommend this Android documentation as further reading if you want more details.
Pentago is a favorite board game of mine, which I used to play regularly with coworkers during lunch (and occasionally during not-lunch). The rules are very simple, and casual games can be played in just a few minutes, but it’s deep enough to still be satisfying if you’re willing to put some thought into your strategy.
In 2009 I wrote a computer player for Pentago in C#, and even managed to cobble together Silverlight and Windows Phone UIs for it that aren’t terrible. The engine uses a negamax algorithm with alpha-beta pruning.
The near-complete obviation of nulls is perhaps the most frequently- (and hilariously-) cited benefit of working in F#, as compared to C#. Nulls certainly still exist in F#, but as a practical matter it really is quite rare that they need to be considered explicitly within an all-F# codebase.
It turns out this cuts both ways. On those infrequent occasions where one does need to check for nulls, F# actually makes it surprisingly difficult to do so safely and efficiently.
In this post I’ve tried to aggregate some best practices and pitfalls, in the form of DOs and DON’Ts, for F# null-checking.
Working on the command line with Powershell, much of the time I have the luxury of dealing directly with rich .NET objects. If I need to sort, filter, or otherwise process cmdlet output, I have easy access to typed properties and methods right at the prompt.
Often, though, I’ll need to wrangle plain text, perhaps from a log file or the output of an executable. In these cases an intermediate step is required in order to extract the typed information (timestamps, substrings, numerical fields, etc) from the plain strings.
This comes up often enough that I whipped up a handy Powershell filter, ‘ro’ (for ‘regex object’), to make it easy: