I've mentioned before that most of SlimTune's core functionality is pluggable. This actually includes the underlying data storage system. The app works through a fairly simple interface, and even SQL is only used by the visualizers and not the core program. To date, the engine in use was Microsoft's SQL Server Compact Edition (SQLCE). With the next release, I'm introducing support for SQLite as well.

Let's recap. Every other profiler I'm aware of works in more or less the same way. While the application is running, data is written to a file. Once the run is complete, the frontend steps in to parse the data and visualize it one way or another. SlimTune on the other hand allows (encourages, in fact) live visualization while the application is running. It also supports very different visualizations that slice the data in entirely different ways. The enabling technology for these features is the use of an embedded database. I'm not sure why no one else has taken this approach, but my theory at the time was that it was a simple matter of performance. Databases have to be manipulated with SQL, have to store everything in tables, etc. I suspected that updating a database so often was a problem. My goal was to write a blindingly fast database backend that would be capable of handling large amounts of data efficiently.

Read the rest of the post at Ventspace.