Mono 2.10, Moonlight 4 Preview 1 Released

[kraftman]

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?

[ciplogic]

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?

So let's agree to some things (philosophy):
- 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.

[ciplogic]

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.

[Stewart]

What architecture, 32 bit or 64 bit, it is running? Thank you.

Both. In fact it is compilable with 32 and 64 bits.