Pootle runs as a server (rather hard to integrate) and because it reads po's from the hdd, many users can really put a load on the server.
On Mon, 2007-10-08 at 19:07 +0300, Alexandru Szasz wrote:
Pootle runs as a server (rather hard to integrate) and because it reads po's from the hdd, many users can really put a load on the server.
Have you actually run a Pootle server?
Pootle has a lot of functionality for web-based translation but it draws a lot of its ability from the Translate Toolkit (which isn't a server). Our current efforts are seeing much of that pushed into the Toolkit and actually someone could relatively easily create an offline translation editor with the Translate Toolkit as a backend.
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...
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.
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.
-
Alan Cox -
Alexandru Szasz -
dwayne＠translate.org.za