Re: Chandler, Python, speed
On Sat, 2009-03-07 at 22:05 +, Ville M. Vainio wrote: Alan G Isaac wrote: 3. Chandler is not really an email client. So specifically, which of its functionalities is it slow, and what evidence if any is there that Python is causing this? I remember reading somewhere that the cause of slowness is/was architectural - perhaps it was that chandler was persisting too much stuff to disk, or something. In any case, this might help you google for more detail. I've been using it, and the only major issue I've got is the long shutdown times, which is caused by backing up a copy of _Everything_ to disk, so that upgrades can happen cleanly - sure that's going to be fixed though. Startup time is a bit slow too, but it's designed to be left open all the time, and it's fairly zippy once it's open IMO. Tim Wintle -- http://mail.python.org/mailman/listinfo/python-list
Re: Chandler, Python, speed
Ville M. Vainio wrote: Alan G Isaac wrote: 3. Chandler is not really an email client. So specifically, which of its functionalities is it slow, and what evidence if any is there that Python is causing this? I remember reading somewhere that the cause of slowness is/was architectural - perhaps it was that chandler was persisting too much stuff to disk, or something. In any case, this might help you google for more detail. Here's the somewhere: http://blog.chandlerproject.org/2008/05/21/rick-rawson-on-why-i-use-chandler-and-what-would-make-me-stop/ QQQ Alex, you’re right that VM usage is a big factor, although there are cases where the CPU is doing too much, too. So far as why this is, there are many contributions. The biggest one is that architectural decisions taken early on in the project meant that way too much data is being persisted. For example, the app persists all schema and GUI layout information, leading to on-disk and mapped memory bloat. (There is also redundancy in the data stored on disk that leads to more of this kind of bloat). QQQ -- http://mail.python.org/mailman/listinfo/python-list
Re: Chandler, Python, speed
Alan G Isaac wrote: 3. Chandler is not really an email client. So specifically, which of its functionalities is it slow, and what evidence if any is there that Python is causing this? I remember reading somewhere that the cause of slowness is/was architectural - perhaps it was that chandler was persisting too much stuff to disk, or something. In any case, this might help you google for more detail. -- http://mail.python.org/mailman/listinfo/python-list
Re: Chandler, Python, speed
On Mar 8, 8:05 am, Ville M. Vainio vivai...@gmail.com wrote: I remember reading somewhere that the cause of slowness is/was architectural - perhaps it was that chandler was persisting too much stuff to disk, or something. In any case, this might help you google for more detail. My understanding was the Philip Eby's oft-quoted Python Is Not Java[1] post was a direct response to how he saw the Chandler project being developed: I was recently looking at the source of a wxPython-based GUI application, about 45.5KLOC in size, not counting the libraries used (e.g. Twisted). The code was written by Java developers who are relatively new to Python, and it suffers from some performance issues (like a 30-second startup time). In examining the code, I found that they had done lots of things that make sense in Java, but which suck terribly in Python. Not because Python is slower than Java, but because there are easier ways to accomplish the same goals in Python, that wouldn't even be possible in Java. [1]: http://dirtsimple.org/2004/12/python-is-not-java.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Chandler, Python, speed
On Mar 2, 1:11 am, Paul Rubin wrote: Mitch Kapor (of Lotus 1-2-3 fame) spent a lot of money hiring very sharp Python programmers to write an email client called Chandler, but from what I understand, progress so far has been disappointing, at least in part for performance reasons. Paul McGuire wrote: Yipes, have you read the book (Dreaming in Code)? Chandler's problems were much more organizational than technical. This discussion makes me curious about a couple things. 1. It is hard to see how Python could make a slow email client. Is that the actual claim? Where is the demand for computational speed coming from? 2. This is especially true for IMAP, where it seems any computationally intensive work (e.g., sorting very large mailboxes) will be done on the server. 3. Chandler is not really an email client. So specifically, which of its functionalities is it slow, and what evidence if any is there that Python is causing this? Thanks, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
