Studio 2017 slow to show results in Translation Results window

I am again experiencing waiting times of up to 30 seconds while Studio 2017 spins its wheels searching for matching segments in the Translation Results window.

Needless to say, even a wait of 5 seconds is unacceptably long and I am considering moving back to Studio 2015 (which is luckily still available on my computer).

Could this be due to the new fragment searching in 2017?

(My computer is fast and the files are on an SSD. I just repaired Studio and rebooted my computer a few hours ago.)

Regards,

Bruce Campbell

ASAP Language Services

Translate

Rate translation

Suggest better translation

Moderator UI

Thread Subject & Description
Studio 2017 slow to show results in Translation Results window I am again experiencing waiting times of up to 30 seconds while Studio 2017 spins its wheels searching for matching segments in the Translation Results window. Needless to say, even a wait of 5 seconds is unacceptably long and I am considering moving back to Studio 2015 (which is luckily still available on my computer). Could this be due to the new fragment searching in 2017? (My computer is fast and the files are on an SSD. I just repaired Studio and rebooted my computer a few hours ago.) Regards, Bruce Campbell ASAP Language Services
Get AI Suggestion

AI Reply

Accept answer Reject Answer

Top Replies

Paul over 3 years ago in reply to davide fezzardi +1 suggested

davide fezzardi I was referring to a standalone tool. The app moved on a bit since this old post and I believe this is what you're after: https://appstore.sdl.com/language/app/tm-lifting/419/

Parents

0 Kevin Flanagan over 8 years ago

Hi, Bruce - could you provide some more information? These factors could be helpful:
* How many TMs in use, with how many TUs
* Language pair concerned
* Whether MatchRepair is enabled
* Whether 'use MT to repair matches' is enabled
Thanks
Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Kevin Flanagan over 8 years ago in reply to Kevin Flanagan

Also -
* Fuzzy match threshold
* whether the slow performance happens on (say) only long segment, or only segments with a lot of fuzzy matches, etc.
Thanks
Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Kevin Flanagan over 8 years ago in reply to Bruce Campbell

Thanks, Bruce. That eliminates a few things. Could you try 'Recompute fuzzy index statistics' under 'Performance and tuning' in the Settings dialog for each TM, to see if that improves fragment recall speed? (I know they may seem unrelated.) If not, would you be able to send the TMs and a source text we can use to reproduce the behaviour?
Thanks
Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Bruce Campbell over 8 years ago in reply to Kevin Flanagan

Hi Kevin,

Unfortunately, I am unable to send the TMs and source text due to reasons of confidentiality ...

Shortly after Studio 2017 was released, I used the "ReindexTms" tool to upgrade all of my TMs for fragment searches.

Would this tool also have done the "Recompute Fuzzy Index Statistics"? (The TM "Performance and Tuning" section of the Settings dialogue states "There is currently no need to recompute the fuzzy index statistics" for all the TMs.)

I have already turned off fragment alignment in the TMs and fragment matching in the TM search settings, so it would take a while to prepare the TMs again.

If you still think it would be worthwhile trying, I could prepare the TMs for the next similar job.

Regards,
Bruce Campbell
ASAP Language Services
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Kevin Flanagan over 8 years ago in reply to Bruce Campbell

Hi, Bruce - completely understand about the TMs. Yes, the 'recompute' thing is still worth trying (and, happily, is a much simpler and faster process than the steps taken by the 'reindex tms' tool). Amongst other things, it sends an explicit instruction to the underlying database to perform an optimisation that otherwise is only applied under certain circumstances. We've found that to make a dramatic difference in some cases. Let us know if it does for you ...
Thanks
Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Paul over 8 years ago in reply to Kevin Flanagan

You could use the reindex TMs tool for this to save time with multiple TMs. The options are for EITHER prepare for upLIFT or Reindex the TMs.

Regards

Paul

Paul Filkin | RWS Group

________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Reject Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Bruce Campbell over 8 years ago in reply to Paul

Hi Paul,

As far as I recall, I checked both the "Re-Index" and "UpLift" boxes when I used the ReindexTms tool.

If the "Re-Index" box is checked, do you know whether the ReindexTms tool perform the "Recompute Fuzzy Index Statistics" ?

Or does this have to be done as a separate step?

Regards,
Bruce Campbell
ASAP Language Services
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Paul over 8 years ago in reply to Bruce Campbell

Hi Bruce,

My bad... shouldn't answer on my phone without more carefully reading the posts. No it does not do the recompute thing. So run this separately as Kevin suggested.

Sorry.

Paul

Paul Filkin | RWS Group

________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Reject Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Bruce Campbell over 8 years ago in reply to Paul

Thank you Paul and Kevin,

I will set the TMs up for fragment matching again for this client.

The next time I translate a file for this client and run into the problem of slow performance in the Translation Results window I will perform a "Recompute Fuzzy Index Statistics" for the TMs and see whether that helps.

Bruce Campbell
ASAP Language Services
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Bruce Campbell over 8 years ago in reply to Bruce Campbell

I just set the 3 TMs up for fragment matching again (ReindexTms tool, both "ReIndex" and "UpLift" boxes checked).

The delays were still occurring when Studio was searching for a match in the TM, so I performed a "Recompute Fuzzy Index Statistics" for all 3 TMs.

Still encountering long delays in the Translation Results window. (Just had several for around 6-7 seconds, and one for 15 seconds.)

Well, something is definitely wrong.

A segment just displayed "Searching..." in the Translation Results window for around 6 MINUTES.

I decided to translate the segment (still displaying "Searching...") and confirm the translation (Ctrl-Alt-Shift-Enter).

The error message "The translation unit was not updated (No error detected.)." was displayed in the Translation Results window.

Studio is still using 25% of my CPU, even though I have now moved on to another segment.

I decided to restart Studio.

The next segment showed "Searching..." in the Translation Results window for 3 minutes before I decided to move the cursor to another segment. That stopped the search.

I just noticed that I do not even have the "TU fragment" box checked in the Translation Memory -> Search dialog.

Studio just used 60% of my CPU for around 15 seconds while searching for a match. It is still using around 40% of my CPU, even though it is not doing anything.

I decided to restart Studio, but even though I closed the program it is still running in the background after 5 minutes, still using around 40% of my CPU.

I presume it is saving my file, so I am a bit reluctant to kill the process. Time to make a tea.

I have checked back several times, but the process is still running in the background after 25 minutes, still using around 40% of my CPU.

I decided to restart my computer and start over on the project.

Regards,
Bruce Campbell
ASAP Language Services
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Kevin Flanagan over 8 years ago in reply to Bruce Campbell

Hi, Bruce - thanks for setting that up and reporting on results. It certainly sounds like something isn't right. It's ... frustrating not having the data to reproduce it. Long shot: is the AnyTM provider involved at all?
Thanks
Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Bruce Campbell over 8 years ago in reply to Kevin Flanagan

Hi Kevin,

I turned off fragment matching again, repaired Studio, did a Windows update, restarted the computer.

Still had problems, so I looked back at your suggestions again and checked my settings.

It turns out that I had the "Maximum number of hits" set to 15 in the Translation Memory -> Search dialog.

I changed this setting to 5, which reduced the maximum waiting time to around 7 seconds (so far).

I have been using this setting since I started using Studio many years ago, and had totally forgotten about it.

It must have been the final straw that broke the camel's (Studio's) back.

Thanks for your help! Hopefully this was all that was needed ...

Best regards,
Bruce
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate

Reply

0 Bruce Campbell over 8 years ago in reply to Kevin Flanagan

Hi Kevin,

I turned off fragment matching again, repaired Studio, did a Windows update, restarted the computer.

Still had problems, so I looked back at your suggestions again and checked my settings.

It turns out that I had the "Maximum number of hits" set to 15 in the Translation Memory -> Search dialog.

I changed this setting to 5, which reduced the maximum waiting time to around 7 seconds (so far).

I have been using this setting since I started using Studio many years ago, and had totally forgotten about it.

It must have been the final straw that broke the camel's (Studio's) back.

Thanks for your help! Hopefully this was all that was needed ...

Best regards,
Bruce
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate

Children

0 Kevin Flanagan over 8 years ago in reply to Bruce Campbell

Hi Bruce - well, that is good news :) ... I'm still a little concerned, because while I would imagine it taking longer (say) to perform MatchRepair for 15 hits rather than 5 (as we've found here) I wouldn't expect it to be stuck for 6 minutes etc. ... Still, I guess we can just monitor the situation for now ...
Thanks
Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate

Trados Studio > 1. Trados Studio

Studio 2017 slow to show results in Translation Results window

Top Replies