I'm not sure the developers forum is the right place for this, but ... no other place seemed more suitable, so ... here goes.

I'm trying to understand why the slimserver has such a large footprint in time and space. By space I mean RAM, by time I mostly mean scan time.

I can read tags for my set of about 8500 songs in about 2 minutes. That's using FOXPRO (an interpreted language, like perl) on a 1.8GHz Pentium with 500MB ram. I did some experiments in a moderately compiled language (Visual Basic 6, the last one before .net). It was 2 orders of magnitude faster. So 12 seconds would be a good expectation for a commercial product.

The memory footprint for the Foxpro compiled code is about 55MB including disk caching, but disk caching seems to be about 40MB of it, so I'm guessing the program footprint itself is about 15MB. As a database program, it builds rapid lookup indexes and everything in that time and space. After it's finished building, I can do keystroke by keystroke interactive song lookup when I'm searching for that song whose title contains the phrase "s'wonderful" or "robin" or whatever.

The machine where slimserver runs is a 600MHz machine with 128MB RAM. It's so slow when it scans the tags, I can have not just a coffee but a shower and a shave while it's doing it. At a third the speed, I would expect about 6 minutes if it's all done in perl, at least an order of magnitude less with some optimization.

The memory footprint seems to be basically everything available on the 128MB machine (just to head off the question, each machine has it's own copy of the song database on a disk local to the machine, so there's no networking differences here).

Slim doesn't report the scan time, so I have accurate numbers, just a feeling that it's slightly longer than forever.

My direct motivation for asking is, I admit, a somewhat unusual application (I DJ with the squeezebox), but the issues raised seem to touch on other peoples experience too, as I found when I tried a search for the keywords "slow startup".

It seems to me the slimserver has two fundamentally different tasks to perform - feeding data to the hardware and managing a user interface.

As it turns out, I don't need the user interface stuff, the database, etc and don't use it (except for debugging & testing). But that's just me.

When I'm DJing, I shut off the rebranded web browser (I think this is the slimserver process).

But can I shut off the whole user interface? The song database, the scanning, everything?

Clearly, the server has to scan the tags of the song it's about to play, in order to put the name up on the screen, to answer CLI calls for what song are we playing, etc. Does it in fact do it that way, or does it go to the database?

And if it goes to the database currently, can that be changed?

It seems to me that the current slim server code should really be 2 modules: hardware driver and user interface.

Feeding the hardware is time critical - if you don't feed it fast enough, you get dropouts.

If they are on the same machine (the "vanilla" installation), they should contend for operating system resources at different priorities and communicate over an interface.

One could also chose to run them on different machines. The hardware driver on a NAS box like the buffalo or linksys, close to the disk data, and the user interface, with it's larger resource needs but less time critical, on some other box "closer" to the user.

In my searching, I found a number of people who wrote about something in the user interface part of the code stopping the hardware interface. And I've done this myself. So it is a concern.

In summary, my questions:

1. Why is tag scanning so resource intensive?

2. I thought the switch to a database system in 6 was supposed to address this problem ... my experience was that it was worse (I switched back to 5, for other reasons, so I can't check at the moment).

3. Given that it is so resource intensive (and potentially, even if you improved it, it's a large problem ... for every improvement in code efficiency, someone out there will have a larger library of songs ... ) how about these solutions:

4. Can the scanning and database service be turned off in the current code (something like scan never, flush cache)? Does anything I care about (song information like title and duration) break?

5. Can the user interface be separated from the "hardware feeding"
a. in the current code?
b. as a future enhancement?

Thanks in advance for your time and considered opinions.

Michael