Posts in category 'hacking'

  • As If I Didn't Have Enough Hobbies

    People who know me well know I’m rather obsessed with music. I love listening to it, I love singing, and I love playing it (mainly on my accoustic guitar, and badly at that). But my playing has always been of the incredibly amateur, self-taught variety… ie, I can fingerpick a simple song or play a decent set of chords, but dear god don’t ask me to improvise on the spot.

    That said, I do sometimes find myself plucking out melodies and playing around a bit with composition. Nothing serious, mind you, and entirely ephemeral, as I never actually record what I’m doing, but I do enjoy the activity, as I find it incredibly organic and instinctive.

    Well, recently, on a whim, I decided to see what was available for music composition applications for my Touch. If you’ve actually read anything on this blog (and odds are you haven’t), you may have heard I picked up a 4g iPod Touch recently, and have been having a great time discovering great applications for making my life easier (Appigo Todo, Trunk Notes, and a ton of others). Well, it turns out there’s also an absolutely unbelievable DAW for iDevices: NanoStudio. And by unbelievable, I mean a full-blown music studio sporting:

    • A powerful drum machine that supports 2 tracks and 4 buses, with a ton of options for pad configuration.
    • 4 full synthesizers with 10 different effects available (and 128 stock presets), X-Y pad controls, a pitch wheel, and a patch panel for tying them all together.
    • A complete multitrack sequencer.
    • A mixer for adjusting the levels on all these lovely things.
    • Support for resampling output, which you can then tie back to the synth or drum machine.
    • Probably tons of other stuff.

    And because it’s all done via a simple touch-based interface, the workflow is dead simple and incredibly natural. And being portable, it means you can compose wherever and whenever you feel like it.

    Suddenly I feel unleashed! Creating music on this thing is unbelievably easy… instead of my clumsy hands limiting my creativity, the only thing stopping me is my brain and my need for sleep (and, I kid you not, killing time with this is way too easy… like, hours disappearing without my noticing).

    So if you’re at all interested in music composition, check NanoStudio out. At $15 it’s an absolute steal. And going forward, the author has plenty of enhancements in the hopper, not to mention a full iPad version in the works (quite honestly, this might be the killer app for me that triggers my investment in an iPad).

  • Dangers of Abstraction

    One of the more impressive things about Pharo/Squeak is the level of depth in the core libraries, and how those libraries build upon each other to create larger, complex structures. One need only look at the Collection hierarchy for an example of this, where myriad collection types are supported in a deep hierarchy that allows for powerful language constructs like:

    aCollection select: aPredicateBlock thenCollect: aMappingBlock
    

    to work across essentially every type of collection available. Unfortunately, building these large software constructs can have negative consequences when one attempts to analyze performance or complexity, and in this post I’ll outline one particular case that bit me a few weeks back.

    My problems all started while I was still experimenting with Magma. Magma, as you may or may not recall (depending on if you’ve read anything else I’ve posted… which you probably haven’t) is a pure-Smalltalk object-oriented database whose end goal is to provide the Smalltalk world with a free, powerful, transparent object store.

    Now, among Magma’s features is a powerful set of collections, which implement the aforementioned collection protocols, while also providing a much-needed feature: querying. In order to make use of this facility, any column that you wish to generate queries over must have an index defined over it, which is really a glorified hash table on the column1. Whenever you create one of these indexes on a collection, the index itself is squirreled away in a file on disk alongside the database. And that’s where the problems come in.

    In my application, a Go game repository, I had a fairly large number of collections sitting around holding references to Game objects (one per individual user, plus one per Go player), and I needed to be able to query each of these collections across a number of features (not the least of which, the tags applied to each game). That meant potentially many thousands of indexes in the system, at least2. And that meant thousands of files on disk for each of those indexes.

    Well, when I first hit the site, I found something rather peculiar: initially accessing an individual collection took a very long time. On the order of a few seconds, at least. Naturally this dismayed me, and so I started profiling the code, in order to pin down the performance issues. And I was, frankly, a little shocked at the outcome.

    It turns out that, deep in the bowels of the Magma index code, Magma makes use of the FileDirectory class to find the index file name for the index itself. Makes sense so far, right? As part of that, it uses some features of the FileDirectory class to identify files with a specific naming convention. And that code reads the entire directory, in order to identify the desired files.

    On the face of it, this should be fine.

    However, internally, that code does a bunch of work to translate those file names from Unicode to internal Squeak character/strings. And it turns out that little bit of code isn’t exactly snappy. Multiply that by thousands of files, and voila, you get horrible performance.

    So believe it or not, the index performance issues had nothing to do with Magma. It was all due to inefficiencies deep in the bowels of Squeak. And hence the subject of this article. Deep abstraction and code reuse is a very good thing, don’t get me wrong. But any time you build up what I think of as a “cathedral” of code, it’s possible for rotting foundations to bite you later.

    1. That, by itself, is a rather onerous requirement, but that’s really a separate issue 

    2. Granted, in retrospect, there may have been a better way to design the DB, but for a very small scale application, this approach sufficed