2009-05-08 11:45:19
A week ago, I wrote a note about Canto's current progress. I think I'll make it a habit. At least until 0.7.0. An informal digest of sorts.
This week has been another of many improvements
Redone threading
I redid the threading work to make it function correctly using two Queue objects and avoiding the custom Thread subclass. Only two threads are used now, one that does all of the heavy lifting and another for input / interface. The result has been a very nice speed up, particularly from previous experimental implementations but also over 0.6.x.
Memory usage
I have decimated Canto's memory footprint. Just by making story dict seamlessly
fetch all unnecessary or large content items from the disk when requested. The
performance hit is negligible and the saving are massive. My copy of canto went
from using 20M to 13M measured via top which doesn't seem to impressive.
However, when you actually measure the size of the Python object heap allocated
from the beginning of canto to normal execution, it went from 8MB to 1MB
(meaning that 12MB of the top value is heap overhead that can't be avoided).
Triggers
Canto can now have an update triggered by more than just a timer and a keybind.
For example, an update can be triggered only when your cursor changes tags,
which can be used to great effect with show_unread to actively filter out
previous items as you read. Another interesting trigger is the signal trigger
which lets Canto be updated by receiving the SIGUSR1 signal. This is so you
can invoke an update at a given time via a cron job, or another application
(most likely to be harnessed via a command line argument like canto --ping).
Other than that, there's been some fixups and cleanups going on throughout. From
here it's onto more canto-inspect work, hooks, and refactoring.
All in all, some neat things showing up, I think.