Start a new topic

Cafe Tran slow to respond

Hello folks,


For whatever reason, when I started working today, CafeTran is slow to respond to any operation, including just typing out translations. There is a slight delay in response no matter what kind of operation I perform. This is really annoying when actually translating.


I already tried restarting the PC, powering off the PC, and updating CafeTran to the latest version.


Nothing is helping, and the project I am currently working on isn't that large of a project.


Any ideas?


Hello,


What is your operating system? Windows?


Sometimes, a Java version can be the culprit. If CafeTran is up to date, make sure you have also installed the latest 64-bit Java version. Can you confirm the version you use, as found in CafeTran Help > About?


How much memory is dedicated to CafeTran in Preferences > Memory > Java memory size (MB)? If it’s 1024, at least double it (depending on your actual RAM).


Some other settings might help as well as described in:


Slowing Down or Exiting Unexpectedly - https://cafetran.freshdesk.com/support/solutions/articles/6000160241-slowing-down-or-exiting-unexpectedly

Running CafeTran in the Battery Mode

https://cafetran.freshdesk.com/support/solutions/articles/6000113091-running-cafetran-in-the-battery-mode


In particular, if the project is not large, but you use big TMs (either attached ones or from Total Recall), test setting Workflow from Automatic to Preliminary memory matching. If possible, don’t do that for your Project TM though.


Another thing regarding TMs:

In 2018 Akua Update 5 (20180409), the option for “greedy” exact matching for TMs has been introduced. Again, you might want to turn this off for big TMs (in TM options).


Here’s the announcement:


Option to turn off the “greedy” exact matching for translation memories - see it in the TM options panel. With this option off, CafeTran does not stop the search at the found exact match(es) for the current segment, but it continues looking for fuzzy matches and fragments. Switching on this option is not recommended for slower computers and huge translation memories.


Igor, did you mean “With the option ON, CafeTran does not stop the search at the found exact match(es) for the current segment”, and Switching OFF this option is not recommended for slower computers and huge translation memories? I’m confused


Finally, I've recently had some performance and CafeTran locking to 100% CPU after a while, with the latest version of everything (CafeTran and Java 10 64 bits). For now, it seems some web resources were to blame, so you may also test closing some websites within CafeTran in your case as well.

Jean, thanks for the thoughtful reply.

However, I use CafeTran everyday, and the project in question was not started yesterday. I was about 35% through it when I started work yesterday.


Well, I just struggled with it yesterday to complete the portion I wanted to finish yesterday.

I then moved on to a different project and then CafeTran was working fine again.


And, then, when I went back and started working on the project with which CafeTran was responding slowly again today, the issue just disappeared. I have not reboot the PC or anything, I just do what I always do and leave the PC running all night.


Very weird phenomenon.


Yeah, my main TM is around 240,000 entries at this point, so I had to start using preliminary matching last year. I think my TM is bigger than most, but CafeTran still responds just about as crisp as with a new memory as long as I use preliminary matching.


However, and I would kind of like some feedback on this, CafeTran uses anywhere between 6 to 10 GB of RAM depending on the project. I did have one large project that forced me to increase the Java memory from 8 GB to 12 GB. The project ended up taking over 10 GB, and until I increased the Java memory, CafeTran was definitely having problems.


I have 32 GB in my current PC, so even with CafeTran taking up to 10, I am OK right now, but at this rate, I will really need to upgrade to 64 GB in another 2 years I think. This seems strange to me because, even though my memory is probably large, the memory itself is only 64 MB.


Igor, could you perhaps comment on this please?

Suggestion: Stop using preliminary matching, import your 240k entries TM in the Total Recall database, use Recall Memory/Segments.


H.

I tried that once before, resulted in much more entries than the actual memory.

Jason: ... much more entries than the actual memory


That should not be possible. Time for Igor to show up.


H.

Fragments matching takes a lot of processing power so the fewer segments the better. Total Recall makes sure that segments in your base which are only needed for the current project's context are loaded into RAM for processing. If you don't use Total Recall, CafeTran loads all the segments from the TMX file into RAM and searches them all for each new segment.


Preliminary Matching introduced before Total Recall also helps as it performs all the matching in one step kicking off before you start the translation and only delivering the results as you reach the current segment, which makes the program more responsive.


"Greedy" exact matching option (ON by default) helps a lot as well. Then, CafeTran gives up any further search for the fragments/subsegments of the current segment if it finds the exact match for this segment. I was reluctant to add this option as it has an impact on the total performance of the system. Really powerful machines with the server spec usually handle that amount of data and processing (e.g. huge translation memories) but with certain tricks just like Total Recall modern "normal" computers should work fine too.


Finally, it is a summer period. You might be suprised how many computers (mostly the older ones with much dust inside) are affected by higher temperatures, turning off or freezing without any warning when the processor is under some more workload. 


1 person likes this
Login to post a comment