- optimizations are not always what make world spinning. Probably you would accept that losing some performance may make sense sometimes. For example bash scripts or pythons are used in fast installers, and updaters.
- my overall experience was that I don't have crashes in either AmaroK or banshee, so "less fragile" is meaningless
- any "hello world" program depends on proprietary hardware (Intel, AMD, Via or whatever), compiler, libraries and OS. One dependency is your video driver or maybe proprietary blob that let your Wifi card to connect. Would you use the proprietary blob that does not disconnect or works right, or would you use Mesa/OSS stack for everything? And if you are the just Intel folks (like happen right now to be), still makes no sense what you are saying, as having "everithing" open will fail on hardware level
Let's go realistic: (your example)
- Banshee was stable in my experience as it was Amarok. The posted video that shows that AmaroK loads slower was not to blame AmaroK for speed, but to point the fact that people use qualifiers but don't use numbers. In the same way, you say the fragility or memory cases, really!? Did you posted bug report to prove that this opensource project use that much of memory? Let's imagine AmaroK: Qt GUI, SqlLite library that store your playlist, multiple views (that embed webkit browsers) in themselves occupy most of AmaroK memory usage. The AmaroK logic is basically meaningless in memory consumption and optimization. Banshee: Gtk GUI, SqlLite library, a bit fewer views (because the Banshee's "multi-view" UI is a but hard to navigate), and at the end the memory usage will be maybe a bit higher than the optimized AmaroK core, but overall the application (I expect) to use significantly less memory than AmaroK. In fact as for myself I don't care about memory, I have 8 G, and practically no netbook/laptop is given with less than 2 GB of memory.
- Mono dependency is like Qt or KdeLibs dependency. For me Qt dependency make me not to pick AmaroK in a gnome environment, but is understandable why. In a similar way, you as a KDE user, you may dislike to use Gnome and Banshee alike. The runtime that is "after the covers" it make matters meaningless, right, right? If Mono is evil in itself, people have to justify it why... is a theoretical threat, that is as hurtful as the possibility that a company like Microsoft will notice that antialiasing algorithms from Qt Arthur engine are a variation of ClearType used in Windows XP, so will try to block all Qt applications without a free. Is too fancy and would never happen!? Microsoft did Community Promise over projects like Mono but not over Qt, should we uninstall all Qt applications for that reason?
So kraftman, please start banshee in a Gnome environment (or Xfce one), start Amarok too, and compare memory usages. Then take some actions that you felt that are speed dependent and post some numbers (can be like: adding 1000 songs to library: Amarok: 3 seconds, Banshee 35 seconds). Or whatever post you think make things appear so bad by using Banshee. Maybe you were hit by a bug, maybe really Mono is too slow. Make a case for using C++/Qt as I don't see one. Maybe I was too blinded by Miguel.
I want to make some corrections and there is no EDIT option.
- my original post was about the fact that I cannot thing anyone undergoing a tedious work to improve the code for so long freezing the project. Performance or whatever gains may be substantive, but people want feature and bug fixes, not esoteric "under the hood" rewrites. Didn't you?
- second fix is that: I would use it with or without optimizations AmaroK anyway in KDE. Yet I said that as you will unlikely do it, I will unlikely use it, but as a person trying to keep my word, I will do it for sake of keeping my word. But as is hypothetical talk, is as hypothetical yes. I don't have an ideology of performance, but if a person will take a more than 1 human-year effort for showing that he lives for his values (in this case the "ultimate" optimization of memory, startup performance and so on), I will give a deep respect to him.
At the end I do think that the effort is meaningless, not because AmaroK would start faster or not, but because AmaroK is not a game engine that every frame per second matters. Would it take 0.5 seconds instead of 0.015 in some specific searches, great! But if the specific search is optimized with common sense optimizations, certainly can be achieved a 0.2 seconds, which may be a bit slow, but more than bearable for most people. And after a week of profiling the slow-down, you can implement another feature or fix another bug in AmaroK, not just trying to improve performance that already is good to start with.