Ah everyone's favorite debate. If you want to get into it seriously, I suggest being more precise. Whey you say calibre is "slow" waht do you mean?
1) Some people complain that the GUI is slow. Other people say taht the GUI is fast enough.
2) Some people claim it is slow with large databases, other people say it is fast enough.
3) Some people say it is slow with conversion, other people...
4) Some people say it is slow with news download, ...
5) Startup times are slow
Now as the person that knows the most about this (and yes, ahi I am well aware of those and lots of other pitfalls in string processing), let me shed some light on easch of these problems
1) Almost all the actual GUI rendering happens in compiled (C++) code
2) Calibre actually stores all the metadata in memory, so this is not a database/python/string processing problem. Though I do admit that the performance here can be optimized. In fact, that's on my agenda as aprt of database independence refactoring for 0.7
3) The biggest bottleneck in conversion is parsing of CSS. calibre uses a CSS library that uses regular expression to parse CSS (the regular expression are again in compiled code). This library's performance can be improved, but I am not going to sit down and re-write it.
4) This is slow because the browser simulation library that calibre uses is not multi-threaded, so all actual downloads happen in a single thread. Until I get around to fixing that library,...
5) This is actually one place where using python hurts. But as far as I am concerned, it's worth it.
|