Under Community Review

Set LookAhead, Fragment matching/Match repair to 'off' by default for better performance for those who don't need one or the other of these features

Many users aren't aware of the fact that turning off functions/features of Studio that we don't use, particularly LookAhead and/or Fragment matching/Match repair can significantly speed up Studio's performance. More importantly, it avoids 'crashes' when handling huge amounts of data, for example in an sdlxliff based on a very large or complex file or a merge of several files, and/or with a very large/more than one termbase and/or translation memory. Also on smaller systems file size can be prohibitive so being able to turn off functions that use too much RAM can be invaluable.

Turning off this/these function/s has to be performed either in Project Settings - or under File>Options if you don't work with projects received from 3rd parties or you create your own projects from scratch every time. Project settings always overrule the same settings under File>Options (so changing these settings under File>Options won't change anything when you work on 3rd party projects or projects based on previously-created project templates).

When you are working on a large project and it crashes, you can sometimes prevent it happening again by rebooting your system (thus wiping the RAM so it is more available to Studio on reboot). Much easier, however, to off Match Repair Usage... and/or LookAhead, which is intended to speed up the translation process but if you've opened a huge, complex image-heavy file as an SDLXLIFF, you can find Studio 'hangs' and LookAhead can make things even slower or even crash, and the logical thing in this context is to turn LookAhead off but some users don't know it is on, or even what it is.

Fragment matching/Match repair functionality is very useful if you frequently translate repetitive texts for the same client/s and only parts of a sentence are changed. However, if you translate novels or any other 'one-off' texts, this is far less likely to happen. Better to have Fragment matching/Match repair turned off, and even to have the Fragment Matches window closed in the Editor view, just like some of the other items on the View tab that you can open if you need them. Plus, if you don't even know it exists or have any need for it, it's not going to slow you down by being turned off by default.

It's also a tad complex to know where to turn these functions off, depending whether one works with Translate Single Document, with internally-created project templates, or with client's projects. They've been well advertised and can still be so, with instructions on how to turn them ON. So, please, turn off LookAhead, Fragment matching/Match repair by default. We'll have a lot less complaints on the Community that way. 

Please, you WONDERFUL people in Product Management, please please please consider this idea, as it'll save those of us who try to help others with Studio crashing or going grindingly slow for no apparent reason an awful lot of time...

Important: I'm not saying these (or any other features that can be turned off) are the cause of the issue, not a bit of it! However, turning off a substantial process that is running unnecessarily will free up more RAM to deal with the complexity of whatever is triggering the performance issue/crashing.

I love Studio and MultiTerm and want to make the experience of using these wonderful tools more enjoyable for all users! Slight smile

Alison Field
  • in reply to Alexa Dubreuil-Storer

    Hi Alexa,

    The 'Match Repair' functionality is honestly VERY helpful if you need it, once you get the hang of it. It very much depends on whether you translate mostly new stuff, in which case it won't be as useful as if you translate phrases a part of which are already in the TM. That is when it becomes really useful.
    Fragment Matching-Match Repair and LookAhead are wonderful tools but it's not necessary to have them turned on when you don't need them. A new user is not likely to be able to reap the benefit of them until the basics have been understood - even the basics are pretty complex to new users of course.

     - which edition of Multifarious deals with Match Repair & Fragment Matching in a way that will help users who find one or the other baffling? I haven't time to look back through as I'm trying to squeeze work around looking after my Mum which would have been sooo easy the week before last as I had no work Cry . I'm happy to say my Mum is on the mend, which is the main thing, it's been touch & go!

    All the best!

    Ali Smiley

  • Hi . You have my vote on this idea - not so much because of the RAM issue, but because I find the "Match repair" functionality more confusing than helpful (apologies to the developers...).

    I have disabled it on all my project templates but if I happen to create a new template, it tends to be ON so I manually switch it off.

  • in reply to Daniel Brockmann

    Hi 

    Me again! I'm working on a HUGE project, proofreading one huge document using a huge termbase I created from another huge, identical document apart from the language pair (DE>enNZ in one and DE>enGB in the other), to standardise the corrections made by the first translator to the second file translated by a different translator. I have both documents open side by side in case I decide a correction made by the second translator needs to be taken across to the document I've already proofed.

    it is a project that came from an agency and is urgent so I'm rushing and thus I forgot to turn off Match Repair in the client's project settings to enable more RAM for the huge functionality required. Guess what? It crashed. If I didn't have to remember to turn off Match repair every time it would not have. This demonstrates, however, that the project settings controlled by the client were set up for the translators, i.e. with Match Repair turned on... that complicates matters for me of course.

    Even if you just added a 'Turn off Match Repair' button to the Review tab it would be SUCH a help to prevent these crashes with big files. I'm an experienced user, but I'm 61 and don't have the best memory so I frequently forget to open the Project Settings and turn off Match repair even though I try to systematically do it after opening every project package I receive. 

    I had just run a terminology verification on the job, that's when it crashed. It took a LONG time because of the size of it, and and now I have to do it again. Not only that but I'd forgotten to save... rushing...

    I'm saying that if it happens to me, who should know what I'm doing, how much more frustrating is it for new users who don't know why it is happening and probably have no idea that LookAhead and Match Repair etc., exist or how they work.

    I'm not complaining, just empathising with those who suffer from this problem regularly...

    All the very best!

    Ali Slight smile

  • in reply to Daniel Brockmann

    Hi

    I am not drawing the conclusion that LookAhead or the other features discussed are the actual cause of crashing and/or slow performance, or 'at play' explicitly. I'm saying that in almost all circumstances that I come across, turning one or the other off will stabilise the problems caused by external factors such as size/age/complexity of files/TMs/TBs> I'm also saying that freeing up RAM without exception solves the problem unless the external content,, the actual cause of the problem, is actually corrupt.

    Thus, more explicit advertising of the new features with instructions of how to turn them on if you want to use them, incorporated into the user instructions would work better than people like me repeatedly advising to turn them off each time the question comes up on the forums, with complex instructions of how and where - which sounds like a criticism of the software's failings but absolutely isn't. There are so many factors out there that we can't control... we can't make the end customers provide stable, efficient state-of-the-art files, TMs or TBs. We can, however, provide the most stable version of Studio and MultiTerm as a starting point, which is with the RAM-hungry features turned off until needed. Maybe an ON/OFF switch plug-in for those who don't have the knowledge to find and turn them on or off in the various settings associated with them?

    That to me would be a much more professional approach than having the features turned on and  repeatedly having to say "If you have an instability problem with certain files/TMs/TBs then turn this or that feature off, and here's how you do it"

    The alternative would be to remove these featurss to apps/plug-ins but that would no doubt cause a storm of criticism in the same way as removing the old coded functionality such as importing a tmx at the project creation stage to a plug-in caused...

    Like I said, I love SDL Trados Studio and MultiTerm and want what is best for its users to enjoy it as much as I do...

    Hope I've explained myself better...

    Have a wonderful day!

    Ali Slight smile

  • Hi - thanks for this one. We are analysing the underlying community report which I think is linked to this idea. At this point, I would not yet draw the conclusion that LookAhead or other features are at play. There can be other factors leading to such problems. Once we have fully analysed the problem, we can then take necessary action but it might be in other areas not related to LookAhead or fragment matching. The defaults currently in place are the result of looking at the user base at large and trying to find the best balance of settings. These are: LookAhead = on, fragment searching for "whole TU fragments" = on, fragment searching for "partial TU fragments" = off (also for fuzzy match repair we have a mix of on/off to ensure best performance but still get the benefit of the feature in many scenarios).

    Especially partial TU fragment matching can be very interesting in certain types of documents, but across the board we found that that setting can cause slower performance especially when working with large TMs. Whole TU fragments are very fast to find so that is why that is on by default.

    I am also very aware that this can be a bit of a philosophical conversation also - do we want to make Studio potentially more difficult to use by hiding certain very useful defaults and users rarely discover them, or do we set certain defaults to on so that users can maximise the use of their resources a bit better? It's a tricky balance Slight smile but I would say that it seems to be best for the user base. However, we do need to look at any instability and fully understand what's at play - if as part of that LookAhead needs to be made more robust, then that would be what we would do. But it might not be at play at least explicitly here - rather it might be an implicit issue. Hopefully we can fully understand this and take any action moving forward.