Lightning fast search

[Drev]

Hello,

MediaMonkey is a fantastic program, and I love the way you run this forum.

For starters, your search is awesome. Just the fact that I can effectively do a logical 'and' with two text fields is almost the Holy Grail for me, I have been searching for somethig to do this for a long long time. The search speed is so much better than my MWP9beta. The minimalist feel and approach of the program makes it run fast and lean, which is heaven. My lowly 450 MHz Celeron is not being renderd punch-drunk by bloatware, as often happens.

Now for the lightning search: This search would be most effective when the average user goes through a long stretch without adding songs to the database. Since the database is stable, a pure-text-file copy of the database could be generated to support the lightning search. I am assuming that a search through a pure text file would take a few milliseconds max for the average processor. Hence the search results could be displayed instantly. When you click on the song to play it. the line mumber of line you click on in the text file is used as a pointer to the actual song in the database.

Also, by maintaining multiple text files representing the different sort views of the database, (perhaps only for the most popular sort fields) the sort function for the song database would also be instantaneous.

Finally, the lightning sort would simply have to monitor the 'database modified' bit to determine if the user would have to be prompted to resynchronize the lightning sort function, which might take a minute or two to do.

The bottom line: I have 128 MB of memory on my machine.... how great it would be to have lightning fast access to my 10,000 song database by loading a striped-down version of the database into into MEMORY when the program boots.

The down side: It would lengthen the boot time for the program...

That's it!

Drev

[Lowlander]

With 128mb wouldn't you want a program to store as little as possible in the memory?

The problem of speed does exist and is probably more noticeble on slower machines. MM has chosen to use the DB on the HDD instead of memory because this allows for the DB to be used by multiple machines at the same time.
So yeah the DB in memory wouldn't work. As for textfiles that could be a solution, but I'm not sure how much speed gain there will be. And I think many users do a lot of updating to the DB which would require these textfiles to be updated often.

We'll see what the program makers think, but I personally can hang on second.

[Guest]

Hello,

>With 128mb wouldn't you want a program to store as little as possible in
>the memory?

Heh... with all due respect Lowlander, I will assume that you are young in years. 128 MB is an utterly fantastic amount of memory that cost a large fortune some time in the dim dark past. A fameous guy once said that a personal computer would never need more than 640k of memory.

So if you reserved 4 Meg of your 128 Meg (or more) of memory to have a stripped down version of your database to support lightning fast searches, your computer should still run fine.

> MM has chosen to use the DB on the HDD instead of memory because > this allows for the DB to be used by multiple machines at the same >time.

Perhaps, but that is pure esoterica for the average user. I will assume that very very few people will use the aforementioned feature. It certainly will NOT happen in the workplace. I can only see college dorms using this feature.

Drev

[Lowlander]

Yep, I'm young, but I know about bill saying the magic memory words.

I don't know what is run on your machine, but 4mb isn't that much. As for a faster search and even faster loading of the tracklistings this has been requested by more people. I myself am fine with the way it works now.

As for using one DB over a network. I think more and more people will have home networks and as such I believe it's a useful feature.

That results me saying the last thing: I hope that MM will provide a faster search in the future so you'll be a satisfied user.

Good luck