| |||||||||||||
Tomboy, Gnote, and the limits of forksTomboy, Gnote, and the limits of forksPosted May 4, 2009 12:29 UTC (Mon) by liljencrantz (subscriber, #28458)In reply to: Tomboy, Gnote, and the limits of forks by ms Parent article: Tomboy, Gnote, and the limits of forks
Agreed about the value of higher level languages, but the performance of most projects written in higher level languages (Tomboy, Beagle, Eclipse, Vuze, Tomcat, Rails, Django) is pretty offensive. I don't know how much of this is badly optimized VM implementations, how much is that developers using managed languages don't understand optimization and how much is that because they use such powerful languages, they can code faster and have more time on their hands to implement slow and useless features, but for one reason or another, most large managed applications, both clinet- and server side, are a slow, bloated mess.
I believe that the problems with high level languages are fixable, and that higher level languages are the way ahead, but it is definitely a bumpy ride.
(Log in to post comments)
Tomboy, Gnote, and the limits of forks Posted May 4, 2009 12:44 UTC (Mon) by ms (subscriber, #41272) [Link]
Yeah, I think that's probably fair. However, don't forget that the act of compiling a language which is already close to the metal (eg C) is a much easier task, and C compiler writers have a pretty big head start. The kind of things going on in the CLI and JVM are pretty breathtaking and very sophisticated. If you compare the performance of the JVMs now to when Java first came out, the difference is astonishing. Obviously, however, just as new optimisations are added to GCC, so there is still more work that can be done in all compilers and interpreters.
I have to say I don't enormously understand people getting upset with obscene memory usage, so long as it's not leaky. RAM's pretty cheap, and a standard box is 4GB RAM these days. Even firefox, which I have with about 80 tabs open is currently only eating 25% of that right now. Of course, the situation is different on a mobile or otherwise constrained device, but then again, for such a device you probably wouldn't aim for so many features. The issue about leaky is key though - a good programmer need not spend too much thought ensuring their program doesn't leak memory when writing in higher-level languages. I've seen many good programmers lose weeks trying to track down leaks in C++ programs.
Tomboy, Gnote, and the limits of forks Posted May 4, 2009 16:29 UTC (Mon) by sbergman27 (guest, #10767) [Link]
"""
I have to say I don't enormously understand people getting upset with obscene memory usage, so long as it's not leaky. RAM's pretty cheap, and a standard box is 4GB RAM these days. """
And my largest XDMCP/NX server runs 60 Gnome desktops. 32MB + 7MB per note represents 2G just to have the program open and almost 0.5G per user*note. If each user had 10 notes, I'd be looking at 6G of memory use. The current server maxes out at 12G. Your "My Computer" style of thinking, applied broadly, would absolutely *cripple* Linux on the corporate desktop. Fortunately, Tomboy's functionality is completely inconsequential, and there are saner options available to people who do have some need for it.
Obscene memory usage vs. memory leaks Posted May 7, 2009 16:53 UTC (Thu) by anton (guest, #25547) [Link] I have to say I don't enormously understand people getting upset with obscene memory usage, so long as it's not leaky.Obscene memory usage is obscene. I don't understand your obsession with memory leaks. Some programs
such as OS kernels that are intended to run forever certainly should
not be leaky, but for, say, Even for a long-lived note-taking program, if it, e.g., leaked all the strings that the user inputs that would be a small amount of leakage compared to the obscene memory use of Tomboy; I doubt that the user creates and deletes notes containing MBs of strings. Moreover, I have seen programs that just get worse by trying to avoid memory leaks. E.g., Netscape 4.72 grew quite a lot over its lifetime (very much like a leaking program), but when it was paged out and I wanted to exit from it, it would take several minutes to page in all that memory, apparently because it wanted to free it so that some leakage-detecting tool would be satisfied. It would be more responsive and reduce memory pressure to just exit without freeing all the memory explicitly.
Tomboy, Gnote, and the limits of forks Posted May 7, 2009 18:15 UTC (Thu) by jordanb (guest, #45668) [Link]
> I have to say I don't enormously understand people getting upset with
> obscene memory usage, so long as it's not leaky.
"I don't understand why everyone's getting upset that the reservoir is running dry, so long as nobody is letting the faucet drip."
Tomboy, Gnote, and the limits of forks Posted May 4, 2009 15:08 UTC (Mon) by sbergman27 (guest, #10767) [Link]
I would not put Rails and Django in the same category. Not at all. Yes, Rails has some pretty serious and well known scaling problems. But Django was born out of the high pressure, high volume world of online journalism, and runs sites like http://www.washingtonpost.com. and http://www.curse.com. Curse was serving up to 500,000 pages per hour a year ago. Not sure how their loads might have changed in the intervening year.
You can't just dump "web frameworks" all into one performance category.
Tomboy, Gnote, and the limits of forks Posted May 4, 2009 22:01 UTC (Mon) by liljencrantz (subscriber, #28458) [Link]
Heh. It's a matter of perspective. Sure Rails and Ruby are significantly slower than Django and Python, so from that perspective, it's unfair to lump them together. But on the other hand, have you any idea how slow e.g. string processing is in Python compared to a well designed string library in C (E.g. _not_ standard C strings)? Pythons immutable strings and things like character access causing a new string object to be created makes e.g. text parsing so much slower that it's not even funny any more. And if you start using cStringIO, things suddenly don't feel very high level any more. Python, in my experience, is a lot slower than Java, so there is this 1-2-3-4 pecking order of C-Java-Python-Ruby, but from a C coders perspective, all interpreted languages are simply painfully slow.
But on the other hand, not all code needs to be fast. I've written Ruby and Python applications and enjoyed the powerful and convenient features Rails has to offer.
I guess one has to evaluate the performance requirements of each new project, and use as high level a language as possible.
Tomboy, Gnote, and the limits of forks Posted May 5, 2009 20:02 UTC (Tue) by salimma (subscriber, #34460) [Link]
Standard C strings cannot be compared to a string in a higher level language (e.g. Java, Python). No Unicode support, no bounds checking, etc. I agree, though, that compared to Python 3's closest equivalent, byte array, the C implementation will be faster in performance. I doubt you'd be as productive writing string-manipulating code in C, though.
Tomboy, Gnote, and the limits of forks Posted May 5, 2009 20:12 UTC (Tue) by jordanb (guest, #45668) [Link]
Not only that but you'll likely write buggy code. Not even getting into mangling Unicode, there's the problems with butchering any string that contains a NUL character. Also since it's such a PITA to do dynamically allocated strings you'll probably also start imposing silly restrictions on string length just to get things done.
Tomboy, Gnote, and the limits of forks Posted May 6, 2009 3:30 UTC (Wed) by shmget (subscriber, #58347) [Link]
String is a very basic problem. basic as in 'used all the time' - not basic as 'easy'.
Yes writing a god string library in C is some work, but you have to do that only once.
"there's the problems with butchering any string that contains a NULL character."
So you are left with dealing with 'string' that actually contain the character NULL... and quite frankly that is practically irrelevant.
Furthermore, a good String library will keep track of size -- without using the C zero-terminated convention -- for performance and memory management reason, so even the irrelevant 'problem' of NULL in a string is actually covered as a side effect....
The whole 'memory management is hard' theme is a red herring. Good design is hard, good coding is hard, yes... but memory management is really a question of disciple and habit, and after a while if become second nature.
Tomboy, Gnote, and the limits of forks Posted May 7, 2009 20:21 UTC (Thu) by liljencrantz (subscriber, #28458) [Link]
Agreed. Which is why I very explicitly stated in my original post that when I talked about string handling in C, I did _not_ mean plain C strings. There are _plenty_ of very high performance string libraries for C. Libraries that support Unicode, bounds checking, O(1) complexity for inserting data into the middle of a string, O(1) complexity for creating sub strings and various other very nifty features that often make them _faster_ then C strings, in addition to being safer. And performance-wise, they are a significant win over e.g. Python.
|
|||||||||||||