Quote:
Originally Posted by midiwall
The problem in this case is processor power and memory available for caching. The ARM7 ain't no P4, and having a ton of RAM available is REALLY nice for building hash tables.
The database engine in the original H10 firmware is running in a total of 24k - that's code AND data space, including the data space available for rebuilding. It does fine at retrieval, but it's a dog for rebuilds.
Now starting from scratch with a totally new OS core and real memory management is a HUGE advantage, but then we're back to looking at the horsepower of the ARM7.
Plus, doing an external app lets you have access to a much smoother dev environment, the ability to build a nice GUI, add a bunch of sorting and catalog options, etc.
|
Heh, don't worry, I understood that
.
I see what you mean. The processor speeds and available memory (I was under the impression the H10 features a 32mb buffer or so, please correct me if I am wrong) are of course a major limitation in what can and can't be done, and there is nothing short of a hardware upgrade that can be done to increase those. However, I never saw database construction as a task that I would carry out often, I'm not sure if this is just me, but I don't tend to update my database very often as I am not getting new songs very often. If there is something I am missing, please, let me know, but I can't see that as a good use of channeling time and effort into something that isn't really a major issue. I do understand that a person with a great amount of songs could suffer from the limited amount of memory it contains, however, could this not be solved by optimization to the current database construction coding?