Quote Originally Posted by ciplogic View Post
AmaroK will certainly will go faster if you will take its all code, look for all abstractions and write them without iterators, without collections, databases, using raw code. Instead parsing xml files, you will have to set a binary packaged format, that is binary efficient (can be LZ compressed) so people with slow disks will get it running faster. Another area you can improve, is to make all plugins part of AmaroC inside application, no memory mapping at startup, no wasted memory. At the end, to be lightning fast, you will have to rewrite all SqlLite database code to an optimized C, and for slow areas, look to generated assembly code (use for Gcc the -s flag) and try to find a reduced form for them. In this way, (no joke intended) AmaroC may start 2-3 times faster than Banshee (for the same library size), it may be running around 4-5 times faster, if not more, in searching in the music library and so on.
As you know and have all tools to optimize, I guarantee to you, even AmaroK is a big project, in two years time, you can do it! I will install it as a default player if you will do it. Will you do it? I would love to write to you bug reports (sarcastic).
Do you feel right to that? Or you think is worthless?
Excluding the rest of the meaningless talk I wonder why wouldn't you use Amarok now, but after some optimization? It's already faster, uses less memory and it's much less fragile than banshee. It also doesn't depend on mono. Logic fail?