Announcement

Collapse
No announcement yet.

Mono 2.10, Moonlight 4 Preview 1 Released

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by ciplogic View Post
    So I've computed all benchmarks with arguments: 20000 out.txt (meaning compute Pi with 20000 digits and write the output to out.txt) and this is the timing:
    .Net 3.5SP1/4.0 (32 bit): 20935 ms.

    Mono 2.10:
    mono --gc=sgen --llvm TimmedPi.exe (32 bit): 20608 ms.
    mono --gc=sgen -O=all TimmedPi.exe (32 bit): 21028 ms.

    JDK 7.0 (64 bit): 15584 ms. I did install 32 bit but cause of my incompetence I've got class not found at startup, I really ask anyone who wants to test this code to do it.
    VS/C++ 2010, I've got the best timing based on all options I found on Release configuration, and I've checked a lot!: C++: 17738 ms
    So, Java is the *fastest* here and:
    - C++ is 13.82% slower than Java
    - C#/Mono/LLVM: 32.24 % slower than Java / 16.17% slower than C++
    - C#/.Net: 34.33 % slower than Java / 18.02% slower than C++
    - C#/Mono: 34.93 % slower than Java / 18.54% slower than C++

    I've tried timings on Linux but I think I've did something terribly wrong and GCC gets on my machine around 25 seconds (so it gets worse than Mono), Mono timing remains constant and Java is around 16.5-17 seconds (again the fastest). The reason I don't want to show those results to make people to try by themselves those "benchmarks" and to notice how right they are and based on those to get the right conclusion.
    I saw a similar benchmark and Vala was included too. Surprisingly, Vala was noticeably faster than C++ in some of the tests! Mono was the slowest.

    Will you not use an easier to use language (as C#) if you will know from scratch that will run around 20-35% times slower than the best optimized platform you can run, if you feel comfortable in it?
    I wouldn't, because 20-35% is too big performance hit to me (I also don't use Java, because I found it sluggish too). Maybe I could stand if some applications would be made using mono, but only if mono wouldn't came from MS. Using it, we support MS and I don't want to support MS in any single way. There's also too much PR talk from Icaza and from Novell, so there is something wrong (like patents). Btw. someone who chose a name for this project had a good sense of humor. From the Phoronix news:

    Ttiago, an X developer at Nokia, then went to comment on the Microsoft-Nokia deal. "I’m sure MeeGo is not dead by any chance though… Nevertheless, Nokia’s contribution to X11 development will be obviously diminishing. It’s sad. Our Graphics Team were just feeling the first effects of the new introduced culture for pushing whatever work (well the ones we are allowed) to upstream and now all was cracked down. So,unfortunately this won’t happen with the same volume anymore and the collected numbers of 1.10 is definitely a mark for Nokia."
    It's better to use Qt or Vala, because using mono we support .Net and supporting .Net we support MS and Nokia who are our competitors. There's also entire DE (which is great) made using Qt, so logical thing is to support it.

    Comment


    • #62
      Originally posted by smitty3268 View Post
      No, what was said that running everything in the system in .NET would result in a big memory usage increase. You then replied it wouldn't. And now in your last response, i'm not even sure what your final position was.

      So, I'll just ask clearly again: Everything running in .NET, memory usage goes way up? Or not? You have 1 word to reply.
      In one word: no.

      I've explained why twice already. Here's a third time: imagine that the runtime requires 20MB of memory. If you run a single managed app that requires 4MB, you'll load the system with 24MB (400% overhead). If you run 250 managed apps that each requires 4MB, you'll load the system with 1020MB (2% overhead, which is insignificant)

      C++ has the same problem: the C++ runtime is somewhere between 5-10MB, depending on the compiler. Run a single 4MB C++ app and you have between 25-150% overhead. Run 250 C++ apps and the overhead falls to 0.5-1% - again, insignificant.

      Outisde the VM/runtime, managed and unmanaged applications have similar overhead: a .jpg is a .jpg and a .torrent is a .torrent no matter if you manipulate it in .Net, Python, C++ or C.

      I wouldn't, because 20-35% is too big performance hit to me
      FFS, Java is 15% faster than C++ in this benchmark, so you surely should be using Java then?

      15% difference in CPU time will not make an application feel sluggish, don't be ridiculous.

      Comment


      • #63
        Originally posted by kraftman View Post
        It's better to use Qt or Vala, because using mono we support .Net and supporting .Net we support MS and Nokia who are our competitors. There's also entire DE (which is great) made using Qt, so logical thing is to support it.
        If you support Qt by buying a full license, you support indirectly Nokia and those money may be invested in WP7 integration.
        On a similar fashion, Vala just prove the point of C# as being a sane language to develop in.

        I think you don't use Ubuntu, Fedora or Gentoo, because the installer is written in Python which works tens of times slower than a Mono or C/C++ written application. You wrote your own Vala installer, right? right?
        The single distros that uses Qt or Gtk as far as I know are: OpenSuse which to say nice is "Mono based" (at least on Gnome) or Mandriva (having a Gtk/Qt wizard). Or you use that ugly slow Python, that is interpreted, have slow math and wonderful regex and integration capabilities?

        I took a "typical" micro-benchmark to prove some points:
        - OS/libraries/implementation may matter. Is too easy to draw conclusion, but just a small test prove you damn wrong on almost everything. Measure, come with your numbers and probe for example making a video on youtube that why Pinta
        - typical wisdom like Java is slowest may not be true for a warmed up application taking a source 10 years old (that most people rely about)
        - that some people don't want to know the truth, and even they know it, they ignore it
        - even if for one case C++ is the best option (for tight loops I would likely use Fortran, that makes better code generation, but this is not an option it seem, just C++ or C) and provides 2x improvements, they will mostly get unoticed, what means PI with 2000 digits, computed on a today machine in 0.2 seconds?
        - on a desktop limiting factor if you have your bad logic, that do no caching, and so on, and making a stupid loop that works through some tags (supposedly) are slow for other reasons than JIT/runtime. The question is motly: do you use the right level of abstraction for that level of code?
        - hypocrisy: is not the point that this or that language is slow, is just that people want undefinetly defend their point, even is baseless. Let's imagine that C++ was 5 times faster than Mono, as it were around 5 year ago, what did it mean for real usage? Did you tried ever MonoDevelop on an Atom based machine two years ago? I'm not here to say is lightning fast, but is not a snail: some controls were written in C/C++ for performance reasons (was mostly the editing view) and you could develop in it. Today it works even better and I did test/debug using it and was surprisingly fast. The same about Pinta, Banshee. In Qt, QML is slow, because is interpreted! QtWebKit is slow even uses a JIT. For me KDE starts in some (enough many) seconds because loads the KdeWorkspace, Plasma, a lot of frameworks, icons (Oxygene), etc.
        To compare, start time of XFCE MonoDevelop, and Banshee in it is much faster than KDE + Amarok + QtCreator, right, right?

        Comment


        • #64
          Originally posted by ciplogic View Post
          If you support Qt by buying a full license, you support indirectly Nokia and those money may be invested in WP7 integration.
          This is probably true, so I wouldn't buy a full license. There's always possibility a fork will be made to kick Nokia's out of the game.

          On a similar fashion, Vala just prove the point of C# as being a sane language to develop in.
          Then why not support Vala instead? It is not only faster (just compare Shotwell to F-spot), but it's also not MS.

          I think you don't use Ubuntu, Fedora or Gentoo, because the installer is written in Python which works tens of times slower than a Mono or C/C++ written application. You wrote your own Vala installer, right? right?
          The single distros that uses Qt or Gtk as far as I know are: OpenSuse which to say nice is "Mono based" (at least on Gnome) or Mandriva (having a Gtk/Qt wizard). Or you use that ugly slow Python, that is interpreted, have slow math and wonderful regex and integration capabilities?
          You have some nice ability, because you discovered what my ideal system would look like. You're partially right mentioning Python (which I hate too), but installer isn't something I'm using all the time, so it's less relevant if it's written in C/Python etc. (but it's still important it must be not written in mono - patents/MS).

          I took a "typical" micro-benchmark to prove some points:
          - OS/libraries/implementation may matter. Is too easy to draw conclusion, but just a small test prove you damn wrong on almost everything. Measure, come with your numbers and probe for example making a video on youtube that why Pinta
          - typical wisdom like Java is slowest may not be true for a warmed up application taking a source 10 years old (that most people rely about)
          - that some people don't want to know the truth, and even they know it, they ignore it
          - even if for one case C++ is the best option (for tight loops I would likely use Fortran, that makes better code generation, but this is not an option it seem, just C++ or C) and provides 2x improvements, they will mostly get unoticed, what means PI with 2000 digits, computed on a today machine in 0.2 seconds?
          - on a desktop limiting factor if you have your bad logic, that do no caching, and so on, and making a stupid loop that works through some tags (supposedly) are slow for other reasons than JIT/runtime. The question is motly: do you use the right level of abstraction for that level of code?
          - hypocrisy: is not the point that this or that language is slow, is just that people want undefinetly defend their point, even is baseless. Let's imagine that C++ was 5 times faster than Mono, as it were around 5 year ago, what did it mean for real usage? Did you tried ever MonoDevelop on an Atom based machine two years ago? I'm not here to say is lightning fast, but is not a snail: some controls were written in C/C++ for performance reasons (was mostly the editing view) and you could develop in it. Today it works even better and I did test/debug using it and was surprisingly fast. The same about Pinta, Banshee. In Qt, QML is slow, because is interpreted! QtWebKit is slow even uses a JIT. For me KDE starts in some (enough many) seconds because loads the KdeWorkspace, Plasma, a lot of frameworks, icons (Oxygene), etc.
          The best benchmarks are "try it yourself". I tried Tomboy and Gnote, F-spot and Shotwell, people complain Banshee is damn slow. Guess which apps are the winners here? If Vala application is running smoother and it's not from MS then why are we still talking about mono?

          To compare, start time of XFCE MonoDevelop, and Banshee in it is much faster than KDE + Amarok + QtCreator, right, right?
          I guess XFCE+QtCreator+Amarok is much faster then their mono counterparts. :>

          Comment


          • #65
            Originally posted by kraftman View Post
            This is probably true, so I wouldn't buy a full license. There's always possibility a fork will be made to kick Nokia's out of the game.

            Then why not support Vala instead? It is not only faster (just compare Shotwell to F-spot), but it's also not MS.

            You have some nice ability, because you discovered what my ideal system would look like. You're partially right mentioning Python (which I hate too), but installer isn't something I'm using all the time, so it's less relevant if it's written in C/Python etc. (but it's still important it must be not written in mono - patents/MS).
            As you see, you are flip-flopping (I think you use Ubuntu ) but why not support Vala instead?
            What if MS will attack with a patent about Vala language which is obviously C# based, and _because_ of Community Promise and OIN stuff, will attack just Vala which will be blocked but Mono codebases will remain standing (is a "conspiracy theory scenario" that a lot of anti-mono folks stand). Should you not remove Shotwell or rewrite it in C/GLib only?
            The installer part of Python does not make necessary the installer slow, because installer is IO bound (some of previous talks), Dpgk/Rpm install speed (which is mostly written in C/C++), script configure and so on. This is exactly why Mercurial and TortoiseHG are way faster than SVN in any operations, even Mercurial is Python based and SVN is C++ based. And don't forget about PlasticSCM, which is also way faster than SVN, this one, you know is C#/.Net based.
            At the end Mono is not from Microsoft, but is Free/OSS software covered by Open Invention Network and is corporate backed. Is like Android: even it was attacked by a company (excluding that Android is not OIN backed), it does not equate with the dead of all Android software. If is so, is the same that Unix rights that are now at Novell make you entitled to think that Linux is from Novell, the same creators as Mono. So you should stop using crap from At&t, Novell. What if SCO will attack and win the battle against Novell or IBM? What if Apple have a patented technology in LLVM that blocks future GCC releases? Or Embarcadero (from Borland heritage)? Should you also conclude that compilers are crap from Microsoft and Borland? So you should not use anything under the sun?
            Originally posted by kraftman View Post
            The best benchmarks are "try it yourself". I tried Tomboy and Gnote, F-spot and Shotwell, people complain Banshee is damn slow. Guess which apps are the winners here? If Vala application is running smoother and it's not from MS then why are we still talking about mono?
            :>
            Which applications are winners? In what? Have you really did your benchmark, or you simply look on "virtual memory" and because Mono for example uses more virtual memory. About Banshee people *complained* as being about slow. Did you know that most of Banshee slowness stands in C optimized SqlLite database that your music library plays against? Even using --llvm is documented to not give any visible benefit cause of that? F-Spot and Shotwell are different in may ways, the same about Tomboy. I think for you, as you can see that on plain CPU time, it is obviously an application as Tomboy is not that slow, to stop right now on startup time. Please go to any of your startup scripts and set: MONO_AOT_CACHE environment variable (if you use still Mono) and you will likely have with no other extra setup a fast startup Mono.
            Originally posted by kraftman View Post
            I guess XFCE+QtCreator+Amarok is much faster then their mono counterparts. :>
            Did you tried it? And by how much? (I will not be surprised that still MonoDevelop + Banshee to start faster than QtCreator and AmaroK)
            The point of the phrase was that you should understand that starting slow, is mostly that some applications load more or less frameworks.
            But you as you always move target: "F-Spot is much slower", but by which degree? Slow in startup, as it may be for whatever reason (for example parsing Xml configuration using System.Xml using DOM traversing may be slower than libxml2 C library, JIT time, a not stripped down startup sequence, and so on). Try MONO_AOT_CACHE to identify if the slowness is regarding JIT time or is slow on operations. For me Shotwell is a slimmed down subset of F-Spot, still enough fast and rightly made. For me most of F-Spot slowness was algorithmic: when you navigate in photos it will do twice the resize of pictures, but I think that you will understand that this may be an unsorted bug, not a Mono related performance; tagging happens automatically in all photos both by timeline and by custom tagging: this implementation may be inefficient (I found yet no equivalent powerful implementation in Shotwell). I do think at the end that Shotwell is well written and the F-Spot being an older codebase, for some time almost unmaintained (getting just patches).
            So: "Then why not support Vala instead?", is for whom you put the question? For yourself in your next project? For developer that do hardwork for you and see that there is practically no IDE with a proper Vala debugger (I think that a future MonoDevelop or val(a)ide may introduce it). That you have no migration part if you made a project like 1000 classes (or whatever unit of "information" you may pick) to target Linux as a rewrite is not like renaming files from .cs to .Vala and from .boo to .genie, to target memory leaks with Weak references excluding that you likely have NO tool to spot memory leaks, and no garbage collector to reclaim them? No proper visual environment that integrates in one tool a form of visual editing + vala coding?
            I know, some of my arguments are just about comfort, that me as a developer will gladly lose some percent of performance to make the thing done, at least where this does not matter. Or are you restarting Tomboy at every two minutes and you notice the startup time of 3 seconds? As I've told you, I work in an opensource project (Windows/.Net only) and who knows, if I will target Linux, Mono is _the_ way to do it. It will not happen soon, to be fair, but I will not rewrite in Vala if a "loonatic" will prefer his politically correct language. Will he/she search after that for memory leaks that will definitely appear after this rewrite?

            Comment


            • #66
              Originally posted by smitty3268 View Post
              You should be very careful drawing conclusions from these sorts of micro-benchmarks. What you've shown isn't that a language is 30% faster than another one, but just that its compiler has an optimization for that specific case being tested which is 30% faster. The situation could be completely reversed on another benchmark.
              Yes, in fact the numbers are much less as difference and you're fully right on the "optimization path" that enters in compilers or not. If you will take benchmarks like Linpack, you will see that Mono is even slower than C++, and again C++ slower than Java, but this microbenchmark was mostly relevant in desktop applications (that most Mono applications target): is integer and string based with some branching in it.
              In my experience using .Net is in general as slow as 50% slower than C++ (in desktop applications) but is mostly unnoticeable, because most of time you stay much more on other components as disk/network access, OS routines, GUI loading/layouting, database computing and result. Anyway, if you will have an operation that asks 0.1 seconds in C/C++, you will likely get 0.15 seconds on Mono.
              Other issue that this benchmark showed was just the idea that in the past the benchmark was against Java client VM version, old version registry allocator (that was one of the reason of Java slowness) that was fixed with client (and server virtual machines) in 2005!? in Java 1.5. So is unfair to say today, after 5 years after the fact that Java is still slow (at least on "tight loop" benchmarks). May not be suitable for games, or whatever one limitation of Java JIT or GC may hit someone, but for certain is no reason to make it a non-starter just for biased (like: "it is slow").
              I did tests with Mono 2.10 (which was on line with the topic of this forum thread), I could do them without SGen GC and without LinearIL, and the results may pose in a much worse posture.
              Can you agree that even 100% slowdown may be hardly noticeable in an application as MonoDevelop, that most of the time CPU stay idling? And about Banshee (that most of its slowness is SqlLite based) is much about taking a better time profiling and find bottlenecks in logic and less about remove one runtime, to make someone (i.e. kraftman) to dream nice because that "evil runtime" will not "spoil" thy application.

              Comment


              • #67
                Originally posted by kraftman View Post
                I guess XFCE+QtCreator+Amarok is much faster then their mono counterparts. :>
                As I've predicted, you are wrong again.
                So I've made a video to back up my claims, that likely will start faster:
                Here is a recorded session: http://www.youtube.com/watch?v=cH-VrnIV-rs
                MonoDevelop + Banshee: minute 1:02 to 1:20 (18 seconds)
                QtCreator + AmaroK: minute 1:40 to 2:05 (25 seconds so approx 40% slower)
                In real life, the difference may be even greater as CPU was a bit "starved" as video recording was occurring, so if was about CPU bottleneck, it was likely much greater.
                Also, I've put on advantage Qt counterpart as the OS may cache some libraries of the Mono applications startup and the difference may be extra two seconds in advantage of Mono (to not think I don't understand how things work and make a benchmark just to extrapolate a deficiency of timings)
                May you give your timings?

                Comment


                • #68
                  Originally posted by ciplogic View Post
                  As you see, you are flip-flopping (I think you use Ubuntu ) but why not support Vala instead?
                  What if MS will attack with a patent about Vala language which is obviously C# based, and _because_ of Community Promise and OIN stuff, will attack just Vala which will be blocked but Mono codebases will remain standing (is a "conspiracy theory scenario" that a lot of anti-mono folks stand). Should you not remove Shotwell or rewrite it in C/GLib only?
                  I'm using Kubuntu and Arch (jumping from one to another from time to time). I'd like to see what patents (if any) Vala violates. What we know for sure there's stuff in mono which shouldn't be, because it's not covered by the Community Promise. Still, it's better relying on Vala, because we don't support MS.

                  At the end Mono is not from Microsoft, but is Free/OSS software covered by Open Invention Network and is corporate backed.
                  It's from MS. Icaza's MS guy, he promotes MS products and works for MS. The same about Novell - they work closely with MS, support their technology and use crappy - non GPL (so Linux unfriendly) licenses for their products. It's not enough to be Free/OSS and to be covered by OIN. The point is to be patent free and to not support competitors (like bsd licensed products usually support their competitors which is funny and stupid same time).

                  Is like Android: even it was attacked by a company (excluding that Android is not OIN backed), it does not equate with the dead of all Android software. If is so, is the same that Unix rights that are now at Novell make you entitled to think that Linux is from Novell, the same creators as Mono. So you should stop using crap from At&t, Novell. What if SCO will attack and win the battle against Novell or IBM? What if Apple have a patented technology in LLVM that blocks future GCC releases? Or Embarcadero (from Borland heritage)? Should you also conclude that compilers are crap from Microsoft and Borland? So you should not use anything under the sun?
                  I don't like Novell nearly the same like MS. What if OIN will attack and win the battle against MS, so it will collapse or what is more likely GCC will block future LLVM releases? MS compilers are indeed crap for me.

                  Which applications are winners? In what? Have you really did your benchmark, or you simply look on "virtual memory" and because Mono for example uses more virtual memory.
                  I ran my favorite benchmarks (run, use, close) and made memory measurements (excluding vm).

                  About Banshee people *complained* as being about slow. Did you know that most of Banshee slowness stands in C optimized SqlLite database that your music library plays against?
                  I didn't know, but why Amarok with SQLite isn't slow then?

                  [/QUOTE] Even using --llvm is documented to not give any visible benefit cause of that? F-Spot and Shotwell are different in may ways, the same about Tomboy. I think for you, as you can see that on plain CPU time, it is obviously an application as Tomboy is not that slow, to stop right now on startup time. Please go to any of your startup scripts and set: MONO_AOT_CACHE environment variable (if you use still Mono) and you will likely have with no other extra setup a fast startup Mono.[/QUOTE]

                  I'm not using mono normally, but if this trick helps then why it's not turned on?

                  Did you tried it? And by how much? (I will not be surprised that still MonoDevelop + Banshee to start faster than QtCreator and AmaroK)
                  The point of the phrase was that you should understand that starting slow, is mostly that some applications load more or less frameworks.
                  This could explain why Amarok didn't start faster. However, Amarok is much more powerful then Banshee.

                  But you as you always move target: "F-Spot is much slower", but by which degree? Slow in startup, as it may be for whatever reason (for example parsing Xml configuration using System.Xml using DOM traversing may be slower than libxml2 C library, JIT time, a not stripped down startup sequence, and so on). Try MONO_AOT_CACHE to identify if the slowness is regarding JIT time or is slow on operations. For me Shotwell is a slimmed down subset of F-Spot, still enough fast and rightly made. For me most of F-Spot slowness was algorithmic: when you navigate in photos it will do twice the resize of pictures, but I think that you will understand that this may be an unsorted bug, not a Mono related performance; tagging happens automatically in all photos both by timeline and by custom tagging: this implementation may be inefficient (I found yet no equivalent powerful implementation in Shotwell). I do think at the end that Shotwell is well written and the F-Spot being an older codebase, for some time almost unmaintained (getting just patches).
                  Yep, F-spot had noticeably slower startup then Shotwell last time I tried. However, it could be like you described.

                  So: "Then why not support Vala instead?", is for whom you put the question? For yourself in your next project? For developer that do hardwork for you and see that there is practically no IDE with a proper Vala debugger (I think that a future MonoDevelop or val(a)ide may introduce it). That you have no migration part if you made a project like 1000 classes (or whatever unit of "information" you may pick) to target Linux as a rewrite is not like renaming files from .cs to .Vala and from .boo to .genie, to target memory leaks with Weak references excluding that you likely have NO tool to spot memory leaks, and no garbage collector to reclaim them? No proper visual environment that integrates in one tool a form of visual editing + vala coding?
                  I know, some of my arguments are just about comfort, that me as a developer will gladly lose some percent of performance to make the thing done, at least where this does not matter. Or are you restarting Tomboy at every two minutes and you notice the startup time of 3 seconds? As I've told you, I work in an opensource project (Windows/.Net only) and who knows, if I will target Linux, Mono is _the_ way to do it. It will not happen soon, to be fair, but I will not rewrite in Vala if a "loonatic" will prefer his politically correct language. Will he/she search after that for memory leaks that will definitely appear after this rewrite?
                  I prefer to use and support Qt more than Vala, because my favorite DE is made using Qt. Some things may be like you have already written, but as far end results aren't so optimistic for mono. Maybe this will change, but I hope it won't, because of the obvious reasons.

                  I'll give you timings tomorrow.

                  Comment


                  • #69
                    Originally posted by ciplogic View Post
                    I've tried timings on Linux but I think I've did something terribly wrong and GCC gets on my machine around 25 seconds (so it gets worse than Mono),
                    Just did the bench on Linux (Mint 10 AMD64, slow laptop)


                    $time java Pi 10000 out.txt

                    real 0m7.584s
                    user 0m8.209s
                    sys 0m2.544s
                    $ time ./pi-c 10000 out.txt

                    real 0m6.998s
                    user 0m6.904s
                    sys 0m0.014s
                    $ time ./pi-cpp 10000 out.txt

                    real 0m14.439s
                    user 0m14.252s
                    sys 0m0.029s

                    $ time mono -O=all pi.exe 10000 out.txt

                    real 0m10.828s
                    user 0m10.721s
                    sys 0m0.035s

                    c and c++ versions were compiled with flags "-O3 -msse2"

                    I had a look at the C++ code and it seemd heavily overengeneered. I backported the java code to C++ (just to find out that it looked the same as the original C code) and did the bench for this version again:

                    $time ./pi-cpp2 10000 out2.txt

                    real 0m7.015s
                    user 0m6.915s
                    sys 0m0.010s

                    So we see that C/C++ are basically the same, 2nd is Java and the slowest is mono. However this was quiet an old version of mono (2.6) without LLVM support, so things will probably be faster.

                    Comment


                    • #70
                      [QUOTE=kraftman;179563]I'm using Kubuntu and Arch (jumping from one to another from time to time). I'd like to see what patents (if any) Vala violates. What we know for sure there's stuff in mono which shouldn't be, because it's not covered by the Community Promise. Still, it's better relying on Vala, because we don't support MS.
                      [/QUTOTE]
                      If you relate on Mono technology post, you will see Moonlight dissected, and the single Mono "specific" parts of Mono that are only for Mono may be: the bytecode (MSIL - ECMA-334) and C# language specification (ECMA-335). The rest are in one way or another in a lot of other opensource projects.
                      So considering that Microsoft (or whatever entity that will attack a Mono specific technology that exist in Linux desktop) can attack the things that may be a threat. Vala is C# inspired and you can attack a patent discretionary (as Apple attacked Nokia or HTC, but not Google), theoretically MS can attach with a close notify. Do you want a specific patent? Is the same that most of anti-mono crowd use (none, if you got my point, but the talk is just in case).
                      Another part that MS can attack is to say about bytecode, that even MS made changes in .Net 4 to support multiple platforms and use the same way that Mono did from 1.0 release, so may be a two way attack. Even will be a certain think that MS will win, a Java-to-Dalvik like bytecode converter may be made to run in a modified fronted of Mono Mini VM (this is the core VM).
                      In rest, all the technologis are under threat as Gnome, KDE, Nokia, Cairo antialiasing, etc. It may be a patent anywhere that may be once attacked, but are not specific to Mono, so the talk is as pointless as Netscape/AOL will attack Nokia's QML as it resemble too much with JavaScript, and for this to recommend to anyone to not use QML.
                      Originally posted by kraftman View Post
                      I didn't know, but why Amarok with SQLite isn't slow then?
                      (...)
                      I'm not using mono normally, but if this trick helps then why it's not turned on?
                      Do profiling or see which queries do. And put a bug report (if this is the concern). For my library (of 2K songs) works smooth (for a 2.4 GHz I5 CPU which may be enough fast for this medium collection).
                      Mono work in general by JIT-ting (compiling just as it "hit" methods) so if you put a lot of code at startup sequence, JIT time may be visible. AOT-cache will precompile as a lib-so your bytecode, getting a bit lower performance because for example Mono Mini will notice small functions and it will inline them (but a better startup time). I'm not complaining on startup performance, but if this is what seems to you the most annoying part of your Mono applications, and you are dependent on startup time (as you seem to run just "lightweight logic" applications as Tomboy, Banshee, if you would ever run them) you may enable it.

                      Originally posted by kraftman View Post
                      I prefer to use and support Qt more than Vala, because my favorite DE is made using Qt. Some things may be like you have already written, but as far end results aren't so optimistic for mono. Maybe this will change, but I hope it won't, because of the obvious reasons.
                      I previously said that I like Qt. I was a programmer in Qt around 4 years ago, and GTK one (as GtkMM) around 3 years ago. Gtk applications also look ugly in KDE, and if you dislike them for this reason I also do undestand you fully.

                      Originally posted by kraftman View Post
                      I'll give you timings tomorrow.
                      I wait them.

                      Comment

                      Working...
                      X