As Kermit once almost said, "it's not easy being free."
Having a free and popular download has its advantages. Developers like the platform, they grab updates, they post bugs, they participate in forums, they come to conferences, they read blogs (I hope), ....
But being free and popular also has a downside (beyond the whole "revenue" thing): we don't necessarily know what parts of our libraries people are actually using.
Sure, we know the big-ticket items. We know the features that are most requested, we know the areas that get heavily used because of constant bug reports and JDC votes, we know the industry-trendy areas of the platform that we need to keep working on, etc.
But what's harder to gauge is the use of the more subtle parts of the platform, APIs that developers probably use a little of for specific pieces of functionality, but that don't get much public fanfare because they're just basic plumbing. I mean, I might mention to someone that I got a new granite countertop in the kitchen, but I probably wouldn't bother talking about having installed a brand new drain in the sink. It's just not very exciting.
And what makes this particularly difficult to gauge in a platform as broad and huge as Java is that there are often many different ways of accomplishing the same task.
Take persistent storage for application preferences, for example; I'm talking about the "my app reads this stuff every time it starts" data, not the data stored with particular documents that may not be read at startup. There are so many ways of accomplishing this rudimentary task that I probably can't think of a majority of them. There's the Preferences API, there's the Properties API, there's roll-your-own file approaches, there's lots of different XML-based approaches, ... and on it goes.
Which ones are developers actually using? Any of these? Some I haven't mentioned? None of the above? All of the above? The sad truth is I don't know. It comes back to the problem I stated above; people download our stuff, write the applications, get it to work, ship it ... and we don't know what they decided to use (unless problems crop up; then we hear about it. A lot).
So now we get to the crux of it, the meat in the puff pastry, the cherry in the sundae, the pebble in the shoe:
- What do you use to persist your application data?
At this point, or maybe way back at the beginning, you might ask "Why does he care? Isn't he a graphics guy?". A fair question and one which, in recent weeks, has been much on my mind. Yes, this is pretty far outside the graphics realm. But one of the hats I wear here has a label that says "member of the startup performance team", and it's in this capacity that I care.
XML is often associated with server-side or web-related development. Its angle brackets are spewed all over the place in those realms. In desktop apps, it may be used as a file format, but there tend to be much bigger issues in the desktop space, so XML doesn't get a lot of press for desktop apps.
Because of this history, performance of XML-related technologies has been more server-side focused: how fast can your business logic crank on some DOM thingie? Issues of startup, like how fast can you parse that XML file, are pretty irrelevant in this space; if it only happens once for a long-running server application, it's not worth worrying about.
But if desktop apps are using these technologies to persist data that's read at startup, then it becomes an interesting area in terms of desktop app startup performance. Server apps may stay up for days or weeks at a time, but desktop apps are lucky if they run all day. In this context, the speed at which those apps start up becomes much more crucial. And if there are common things that all applications are doing at startup time, then we'd better make sure those things are performing up to snuff.
So, how about it:
Can you tell me what to tune here? Should I be benchmarking Preferences? Or Properties? Or one (or all) of the several XML-related APIs? Or are people just rolling their own and we should just make sure file IO is fast enough to handle it? Or is this simply not an issue and I can return to thinking about pixel performance?
Lay down a quick comment below if you have any tips here for me. Sure, it's anecdotal evidence, but anything helps.