Track this topic | Pages sur ce sujet: [1 2 3] > | | Utilisateur | Auteur du fil: Grzegorz Gryc Ridiculous Studio 2009 performance for not so huge Excel files... | Grzegorz Gryc Pologne Local time: 12:31
Membre (2005) français vers polonais + ... |
Hi
Test file:
300 kB xls file, 1000 rows, 18 columns (no empty cells, plain text, no formatting at all).
Test machine:
Pentium IV 2,6 GHz, 3 GB RAM, file stored over the LAN (Gigabit Ethernet)
Results:
Trados 2007 Suite (TagEditor)
Opening: 9 min 45 s
Saving: 2 min 10 s
Preview: no internal viewer available, 6 min 5 s in an external viewer (MS Excel 2003), the operation must be repeated for every new preview.
Trados 2009 Studio
Opening: 24 min 15 s.
Saving: not completed (see below)
Preview generation: no internal viewer available, crashed while exporting to the external viewer (MS Excel 2003), the operation must be repeated for every new preview.
MemoQ 3.6
Opening: 21 min 45 s.
Saving: while opening
Preview generation: while opening (internal viewer), instant preview during the translation.
Deja Vu X 7.5.303
Opening: 1 min 20 s.
Saving: while opening
Preview: no internal viewer available, 1 min 50 s to export the file, the operation must be repeated for every new preview.
It's just a "rapid" test for a file a friend send me because it caused export problems in Trados 2006, I was just curious, the times I registered may be slightly inexact...
The test is not exhausive i.e. the results may vary for other xls files (the formatting, images etc. may have a huge impact on these CAT tools comportment).
Résumé
As you see:
The speed winner is incontestably DVX.
The usability winner is MemoQ.
Trados 2007 Suite is still interesting (you can start to work 2 times faster than with MemoQ; the Trados Excel QA plug-in saved my arse several times when I was working on TTX files imported in DVX, DVX lacks this kind of automatic QA for XLS files, so why I use mixed Trados-DVX-Trados workflows here...).
Trados 2009 is a simply a disaster.
Cheers
GG | | | | Maxim Manzhosin Russie Local time: 14:31
 Membre (2008) anglais vers russe |
Could you save the source as HTML, translate in Trados and finally open the translation in Excel?
I don't have Studio 2009 but I've worked with large HTML files in TagEditor 2007. | | | | Grzegorz Gryc Pologne Local time: 12:31
Membre (2005) français vers polonais + ... AUTEUR DU FIL | | Lost in conversion... | Sep 5 |
Maxim Manzhosin wrote:
Could you save the source as HTML, translate in Trados and finally open the translation in Excel?
I don't have Studio 2009 but I've worked with large HTML files in TagEditor 2007. |
|
Of course, it's possible in this case but when the xls file contains diagrams, cross-references, formulas etc., you may have problems.
BTW.
Trados 2007 did open the file.
It's no so bad.
A lot of translation tools are unable to process correctly this kind of files.
Cheers
GG | | | | Miguel Garcia Lopez Espagne Local time: 12:31
 Membre (2008) anglais vers français + ... |
Grzegorz Gryc wrote:
Hi
Test file:
300 kB xls file, 1000 rows, 18 columns (no empty cells, plain text, no formatting at all).
Test machine:
Pentium IV 2,6 GHz, 3 GB RAM, file stored over the LAN (Gigabit Ethernet)
Results:
Trados 2007 Suite (TagEditor)
Opening: 9 min 45 s
Saving: 2 min 10 s
Preview: no internal viewer available, 6 min 5 s in an external viewer (MS Excel 2003), the operation must be repeated for every new preview.
Trados 2009 Studio
Opening: 24 min 15 s.
Saving: not completed (see below)
Preview generation: no internal viewer available, crashed while exporting to the external viewer (MS Excel 2003), the operation must be repeated for every new preview.
MemoQ 3.6
Opening: 21 min 45 s.
Saving: while opening
Preview generation: while opening (internal viewer), instant preview during the translation.
Deja Vu X 7.5.303
Opening: 1 min 20 s.
Saving: while opening
Preview: no internal viewer available, 1 min 50 s to export the file, the operation must be repeated for every new preview.
It's just a "rapid" test for a file a friend send me because it caused export problems in Trados 2006, I was just curious, the times I registered may be slightly inexact...
The test is not exhausive i.e. the results may vary for other xls files (the formatting, images etc. may have a huge impact on these CAT tools comportment).
Résumé
As you see:
The speed winner is incontestably DVX.
The usability winner is MemoQ.
Trados 2007 Suite is still interesting (you can start to work 2 times faster than with MemoQ; the Trados Excel QA plug-in saved my arse several times when I was working on TTX files imported in DVX, DVX lacks this kind of automatic QA for XLS files, so why I use mixed Trados-DVX-Trados workflows here...).
Trados 2009 is a simply a disaster.
Cheers
GG |
|
I agree with you, after trying to use Studio 2009 for several files, I return to use 2007 Suite.
I pay Trados to get the work done, not to wait in front of the computer.
The performance of Studio 2009 is a shame. | | | | Bjørnar Magnussen Norvège Local time: 12:31
 Membre (2002) anglais vers norvégien + ... MODÉRATEUR | | Trados 2009 only as editor | Sep 5 |
Trados 2009 is a simply a disaster.
GG |
|
Trados 2009 is not (yet) among the best tools on the market as far as compatibility is concerned. However it is currently my favourite editor due to the autosuggest function (Deja Vu X comes second).
For an xls file with diagrams etc I would probably use this workflow:
Export unknown segments in TagEditor, Translate in Trados 2009, finalize the file in TagEditor. | | | | Claudia Alvis États-Unis Local time: 05:31 anglais vers espagnol + ... |
I think that Excel file over a LAN might have something that's causing both SDL programs to be so slow. I mean, 24 minutes is too much even by Studio standards. I've seen a similar problem, although not as bad, with one-page, only-text Word documents that take a good couple of minutes. Certain numbered lists in Word caused Studio to be unbelievable slow.
The performance of the Service Pack 1 is much better, although it's still slow compared to other CAT tools. I just created a project based on a large Excel file (several locked and formatted cells and columns, 2500 rows, 27500 words, no cross-references or objects of any kind), I used a TM with over 800k TUs) and it took a little over 11 minutes.
Still, Studio has become the CAT tool of my choice due to its QA features and auto-suggestions. I hope SDL fixes this performance issue once and for all.
Edit: A recurrent problem I've noticed is caused by the TMs. If you're creating a new project based on another one or based on a template, remove whatever TMs you have on the project, then add it again manually. That usually fixes the problem, at least in my case.
[Edited at 2009-09-05 14:28 GMT] | | | | Daniel García Allemagne Local time: 12:31 anglais vers espagnol + ... | | Any difference if file is stored locally? | Sep 5 |
Thanks for posting this.
I was wondering if there was any difference if the file had been stored locally.
I am just wondering if the difference (or part of it) might be because some of apps store their temporary files (for the preview) locally and other store them in the same folder where the work file is.
Daniel | | | | Grzegorz Gryc Pologne Local time: 12:31
Membre (2005) français vers polonais + ... AUTEUR DU FIL | | Another benchmark: Wordfast Pro | Sep 5 |
Claudia Alvis wrote:
I think that Excel file over a LAN might have something that's causing both SDL programs to be so slow. |
|
Yep.
The network access should not be a problem, see the benchmark below.
Wordfast Pro
Opening: 15 s
Saving: in a breeze.
Preview: no internal viewer available, the file is exported in a breeze, just a click.
It's possible.
BTW.
A lot of cells without alphanumeric content were filtered out.
Good, damn good.
| I mean, 24 minutes is too much even by Studio standards. |
|
LOL.
I love these "Studio standards" 
| I've seen a similar problem, although not as bad, with one-page, only-text Word documents that take a good couple of minutes. Certain numbered lists in Word caused Studio to be unbelievable slow. |
|
I remember it was practically impossible to work with InDesign documents over the network (early Trados 2007 builds).
If the SDL guys are unable to optimize I/O operations over LAN, it's not very serious...
I'm using a Pro version, intended to share TMs etc., you see... it's getting really hilarious to share resources without network.
Probably they should develop a telepathy module 
| The performance of the Service Pack 1 is much better, although it's still slow compared to other CAT tools. I just created a project based on a large Excel file (several locked and formatted cells and columns, 2500 rows, 27500 words, no cross-references or objects of any kind), I used a TM with over 800k TUs) and it took a little over 11 minutes. |
|
I used an empty TM and the xls file was really a plain text one...
| Still, Studio has become the CAT tool of my choice due to its QA features and auto-suggestions. I hope SDL fixes this performance issue once and for all. |
|
I hope it will be faster than the Go to the previous segment feature implementation 
Cheers
GG
[Edited at 2009-09-05 18:41 GMT] | | | | Grzegorz Gryc Pologne Local time: 12:31
Membre (2005) français vers polonais + ... AUTEUR DU FIL | | Another benchmark: OmegaT | Sep 5 |
Claudia Alvis wrote:
I think that Excel file over a LAN might have something that's causing both SDL programs to be so slow. |
|
Ehm...
OmegaT 1.8.1_6
Opening: 15 s
Although it's not comparable 1:1 because the xls file was converted first to ods (Open Office format).
Cheers
GG | | | | Grzegorz Gryc Pologne Local time: 12:31
Membre (2005) français vers polonais + ... AUTEUR DU FIL | | Local vs network access... | Sep 5 |
Daniel García wrote:
Thanks for posting this.
I was wondering if there was any difference if the file had been stored locally. |
|
I'm sure it should be somehow faster.
I'l try to retest it... after some other CAT tools 
| I am just wondering if the difference (or part of it) might be because some of apps store their temporary files (for the preview) locally and other store them in the same folder where the work file is. |
|
IMHO it should not make a crucial difference.
With Gigabit Ethernet, you may easily have up to 25 MB/s (sustained), my very old home server has 15 MB/s (it's a 10 or 11 years old machine...).
AFAIK a modern HDD may have transfers like 50-60 MB/s (sustained), so I expect the network operations may be 2-3 time slower than the local access but not 20-30 times slower...
20-30 is arbitrary here but you see the problem is an extremely unefficient architecture in Studio.
In the same conditions, DVX, OmegaT and Wordfast Pro perform at least 20 times faster.
MemoQ is slower but it creates a real time preview environment in the same time, so it can't be compared 1:1.
Cheers
GG
[Edited at 2009-09-05 15:48 GMT] | | | | Jabberwock Pologne Local time: 12:31
Membre (2004) anglais vers polonais |
This is quite interesting... Could you test MemoQ without the preview?
I am also wondering about the translation GUI speed. Do you see any perceptible delay in opening and closing the segments or is 2009 so slow only in the management functions?
Well, I guess it does not matter much - we're stuck with 2007 for the years to come... No sane LSP manager will migrate their entire workflow (which in itself is a daunting task!), if it means a deadly hit in performance... Freelancers can live with forty minutes of delays per day, even if it means the caffeine intake rises significantly. If the PM receives files with translation into ten languages and cannot process them in a day, then it is quite another story... | | | | Grzegorz Gryc Pologne Local time: 12:31
Membre (2005) français vers polonais + ... AUTEUR DU FIL | | MemoQ, DVX. GUI performance and another benchmarks: SDLX, Across | Sep 5 |
Jabberwock wrote:
This is quite interesting... Could you test MemoQ without the preview? |
|
It's impossible 
All the operations are made in one step.
It's the philosophy of MemoQ.
Let's say, it takes approx. 15-16 minutes without preview file creation, i.e. it's a little bit slower than Trados 2007 Suite.
IMHO it's not fully optimized.
But the real time preview during the translation is probably worth of it...
| I am also wondering about the translation GUI speed. Do you see any perceptible delay in opening and closing the segments or is 2009 so slow only in the management functions? |
|
Uhm.
It's difficult to say.
Generally T2009 is not so bad (e.g see the opinions of Bjørnar and Claudia) but for me the translation is still slower than in DVX but faster than in TagEditor.
But it's very personal.
I think it's so personal we can start some flame war in a different thread 
| Well, I guess it does not matter much - we're stuck with 2007 for the years to come... No sane LSP manager will migrate their entire workflow (which in itself is a daunting task!), if it means a deadly hit in performance... |
|
Probably you are right.
| Freelancers can live with forty minutes of delays per day, even if it means the caffeine intake rises significantly. |
|
Huh...
With DVX, you can always open a second instance, start to translate another job and reduce the caffeine intake 
| If the PM receives files with translation into ten languages and cannot process them in a day, then it is quite another story... |
|
True.
So why a lot of intelligent translation offices process only one language and uses a text processing tool (e.g. a PERL based one) in order to generate the remaining target languages.
Here, the DVX architecture is the most efficient because the import is done only one time.
Of course, the pretlanslation/analysis must be done for all the languages.
BTW.
Another benchmarks:
SDLX 2007 (build 7080)
Opening: process killed after approx. 1 hour, sorry...
Across 5.0
Opening: approx. 5 minutes (including a lot of illogical tasks related to the workflow).
I say illogical because an analysis against empty termbases/TMs don't make sense, I think...
Nevertheless, it's 5 times more rapid than Trados 2009 Studio... and finished...
Cheers
GG
[Edited at 2009-09-05 18:37 GMT] | | | | Williamson Royaume-Uni Local time: 11:31 flamand vers anglais + ... |
Trados 2009 studio Beta version, marketed as a normal release. A patch is in the making. | | | | Gergely Vandor Hongrie Local time: 12:31
Membre (Nov 2009) anglais vers hongrois | | MemoQ preview = extra processing at import | Sep 7 |
Jabberwock wrote:
This is quite interesting... Could you test MemoQ without the preview?
|
|
Very good point. It would be interesting to see how MemoQ performs on equal grounds. None of the other tools provide real time preview.
Best regards,
Gergely Vandor
Kilgray | | | | Gergely Vandor Hongrie Local time: 12:31
Membre (Nov 2009) anglais vers hongrois | | importing without preview in MemoQ | Sep 7 |
Grzegorz Gryc wrote:
Jabberwock wrote:
This is quite interesting... Could you test MemoQ without the preview? |
|
It's impossible 
|
|
No, it isn't. 
Tools > Options > Appearance, locations > Enable preview for translation.
Excuse me that I'm giving MemoQ support here. 
Gergely | | | | | Pages sur ce sujet: [1 2 3] > | To report site rules violations or get help, contact a site moderator | Ridiculous Studio 2009 performance for not so huge Excel files... |