On Tue, 2007-10-09 at 06:06 -0400, Alan Cox wrote:
On Tue, Oct 09, 2007 at 10:18:30AM +0200, Dwayne Bailey wrote:
> Yes it doesn't use a database and parses files into memory (although
> we're caching much data in a database in current development work). But
> of the people who use the system we have no complaints and of those
> who've stress tested it, they actually contributed performance fixes. I
> guess what I'm saying is that performance issues are a nice theory and
> easily worked around when found by pushing data into a database...
Since when has reading po files off disk or parsing them been a highly
cpu demanding experience - it migth be in java but in C the cost of parsing
po files is tiny, maybe even less than the cost of filling the cache with
some monster sql database and then putting back pootle.
Well we parse in Python so there is a potential to be slow. I;ve done
work to use libgettextpo so the toolkit in trunk is parsing in C, I
don't have the numbers but observed time halving for counting a large
number of PO files.
The caching that we have done is mostly around statistics - word counts,
etc. So not that large, big if we cache translations. Yes it can become
a monster, a SQLite database with count from all .mo file (the toolkit
can read those) on my Fedora box goes over 1GB in size. So monster it
can be, I'm not sure what size that would be if you where tracking all
products translatable on a Fedora release.