On Wed, 06 May 2009, Szak�ts Viktor wrote: Hi,
> I'm testing .po generation in hbmk2. This project has more than 500 > source files with translatable texts, that equals to the amount of .pots > to be merged. There are 8 languages currently generated. > What I noticed is that POTMerge() -> LoadPOTFiles() -> probably > __i18n_potArrayJoin() gets slower and slower by processing .pot > files which makes processing quite long, about 10 minutes on my > machine. > Do you think it's possible to speed that up? It may be an option to > merge POTMerge() and AutoTrans() into one, as they are called next > to each other in this scenario. ( That may also need reverse logic > to retain existing translations. ) It should not give noticeable improvement. If you try to execute autotrans for each .pot file then maybe in the most optimistic case you will reduce the time by half - IMHO not worth to make the internal logic more complicated then necessary. If you first merge all .pot files and then call autotrans for such merged new and old file then it can give rather very small improvement which can be reduced if you compile the old .pot file to .hbl and use it instead of the new one. Merging all .pot file into single one before executing autotrans seems to be optimal solution and can be easy adopted work with -j+<file> compile time switch if we add it. -j+<file> means add new translation to the ones which already exist in <file> what should finally give the same translation set as after merging all .pot file generated for each .prg module. Probably the one thing which can give important speed improvement when you merge many .pot files is reusing hIndex in __I18N_POTARRAYJOIN() for each next file. This can be done in few lines and I'll commit it ASAP. Please check how it will change the time of: hb18n -m *.pot -oresult.po executed against your 500 .pot files. After this modification it will be hard to find sth what can reduce the cost by better algorithm. We can still reduce it a little bit, f.e. by replacing some [AH]Clone() with simple assign or reusing some already decoded data but it will not reduce the cost level. Anyhow the whole process can be still improved by rewriting it in C using different internal structures. The question is if we want to make it. Current .prg code give us a chance that we will find developers who add some extensions like tools for manual translations of .pot files by users. Just simply not everyone knows C. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
