The recent loader work has now reached a point where the difference is difficult to miss.

One of our older benchmarks recorded 3,902 songs taking 791.658415 seconds to load. That is just over thirteen minutes. When we began the current round of testing, our active 3,722-song library was still taking 677.246704 seconds.

After working through the loader piece by piece, that same library reached repeated runs of around forty-six seconds. A later validation run completed in 44.012848 seconds. There was no single switch responsible for that change. This was on a USB external 2.5" 5400RPM 2009 laptop drive we had lying around. On newer NVME/SSD architecture, the gains will be much higher.

A large amount of the loading time came from work being repeated, or from expensive checks being used before the engine knew whether they were necessary.

The first major improvement came from format detection. Ordinary SSC files were sometimes being checked as possible Pump content based on signals that were too broad. That preserved compatibility, but it also sent thousands of files through parser work they did not need.

We tightened those checks so Pump content is still recognised where the files provide real evidence, while ordinary SSC charts can continue through the normal path.

The loader was also asking the filesystem many of the same questions more than once. Once a folder had already been listed, that information could often answer basic media checks without probing the same files again.

Chart data had a similar problem. Some load-time tasks were repeatedly compressing and rebuilding note data that was already available in memory. Those tasks can now use the existing chart data instead of recreating it during the same load.

Audio length checks were another large cost. The older tidy-up path could fully open audio files while loading, even when the engine only needed enough information to complete cache data. On a cold startup across several thousand songs, that became extremely expensive.

The newer loader path uses quicker audio length information where that is sufficient, while leaving full audio opening to the parts of the engine that actually require it.

Several smaller changes contributed as well. Empty parser routes are skipped, PIU work is avoided when there are no candidates, cache hashing spends less time inside the write lock, and loader state that should belong to one worker is no longer shared across the whole process.

None of these changes would matter if the faster loader produced a different library.

Throughout the main validation runs, the song, step, Pump and autogen counts remained stable. The improvement came from removing unnecessary work, not from silently dropping content.

There is still more loader work to do, but startup for this test library has fallen from more than eleven minutes to under one minute.

That is a substantial change players with large collections should notice immediately.