I'm experiencing an issue with Cafetran's resource use. I'm using a 2014 Retina Macbook Pro with i5 2,6 GHz, 8 GB of RAM and a solid state drive running the final build of El Capitan 10.11. The laptop is still pretty new and maintains a stable 8-9 hour battery life (~120 load cycles) while using Safari, MS Office and other simple, everyday tools.
However, using Cafetran decreases the battery life to approximately 2,5 - 3 hours, the fan fires up to more than 3,000 rpm (idle value = ~1,300), also the temperatures rise considerably. I've already tried changing the autosave setting value for glossaries, projects and memories to 10.
At the moment I'm using a single TMX memory consisting of little less than 12,000 entries and a couple of glossaries with several hundred terms.
I'm using the full version of Cafetran, revision 2015101301 released today and I have the newest java 8 installed.
The above happens regardless of the translated file's size. It makes no difference if the document contains five thousand characters or a hundred thousand.
I'm attaching a screenshot of the Activity Monitor's energy tab, with the second and third columns being Energy Impact and Average Energy Impact. That's after ten minutes of working in Cafetran. CPU Usage stays between 15 and 20%.
I had the same issue with older revisions of Cafetran on my old 2010 Macbook white running Mavericks and, later on, Yosemite. However, it wasn't that much of an issue since that laptop wouldn't last more than two hours on a single charge anyway.
As my hardware finally allows to spend more than a couple of hours away from the wall socket, it would be great to take advantage of it.
I would be very grateful for any help on this matter.
...or is it supposed to be like that?
Well, I know that CT and Dragon can be RAM-intensive (but on an iMac, not on a Macbook). Can you tell which version of Dragon is being concerned here?
>Can you tell which version of Dragon is being concerned here?
The latest. And the strange thing is, that with the other CAT tool (database based) no problems exist. Well, let me check that quickly once more.
The victim is a bit tired of using all those machines and all those environments that don’t play together. In 50 years, translators going to say, oh it was difficult back then when it was all in its infancy.
Maybe I should get back working as an interpreter, so I only have to rely on my brain and not on a machine.
As far as I understood it in Swordfish you got the choice to create a remote (saved in the cloud) or an internal (saved on your comp) database. I was simply creating an internal database and imported my huge TM ENG > DE. I didn’t experience any problems but I must say I didn’t use Dragon with the tool for very long, just some hours. It seemed quiet.
I must say about the MBP that it fires up the ventilator and gets warm just from having 8 tabs open on Firefox and browsing on one, for example, through Facebook. Firefox sometimes can use up to 3 GB of RAM.
Why buy all this expensive stuff when all the software gets heavier and requires more energy? As if we would construct car motors with an extremely high output to drive the same speed as before because the material the car is built of has grown ten times heavier.
I probably don’t understand the underlying complexity of programming software, but it sucks.
>I must say about the MBP that it fires up the ventilator and gets warm just from having 8 tabs open on Firefox and browsing on one, for example, through Facebook. Firefox sometimes can use up to 3 GB of RAM.
I guess that the best browser on a Mac is Apple's own one: Safari.
As a happy and devoted Mac user, I am permanently on the look out for a good CAT tool for this platform. CT comes close to it but the single biggest stumbling block to this becoming my CAT tool of choice is its energy consumption/high CPU usage. You don't need to have a long document or a huge TM; a mere 300-word document with a newly created TM is a sufficient for the CPU usage to spike on my MBP immediately. Since I have to work on battery power a lot, it feels like a race against time every time I launch CT.
I have used Wordfast Pro on Mac and worked on some big projects with huge TMs, etc., but energy use has never been an issue with it. I also use Windows-based CAT tools with Parallels Desktop (yes, I'm afraid I have tainted my Mac with it), but even running Parallels + Windows on battery power isn't as draining as running CT.
I can accept that there might never be a native Mac-based CAT tool any time soon and that any CAT tools available for Mac will probably have to be Java-based, but is Java really the cause? I do all sorts of things on my Mac, some of which are meant to be energy-hungry (like re-encoding multimedia files), but I can categorically state that nothing is as draining as CT. No other Java-based apps have this problem.
I think Igor is doing a fantastic job by constantly adding new functions, listening to and communicating with customers with such energy, etc. Even though energy efficiency isn't the most eye-catching or sexy feature, I consider it to be absolutely fundamental. I'm afraid CT is well below par in this regard and I urge Igor to please have another look at this issue.
Tom: ... yes, I'm afraid I have tainted my Mac with it
I shall never forgive you for that, but at least it allows you to try the experiment I mentioned above: Run CT under Win Windo err Whatever, and see if that would make any difference. I can't believe it's a hardware problem (Apple usually underclocks its processors, especially for MacBooks), can't be Java, so I still think CT for Mac is to blame. If you run CT under "that other OS" and the MacBook doesn't get hot, we will know it's CT's Mac version.
I follow this discussion with interest and can only say that CafeTran is a processor-power hungry app when run with the full features set deployed. You can treat it as a server app or a game without the relieve of the Graphics processor (GPU) that games use. However, it is quite possible to limit the processor usage without compromising much functionality in the laptop/tablet mode. Please see this Knowledge Base article here for the tips. Perhaps it would be a good idea to add a battery mode option in the Project Dashboard to switch to the settings outlined in that article automatically?
Would the storage of project and TM segments in a DB make CafeTran less battery hungry? Though I realise that that would probably imply a complete redesign of CafeTran's RAM based approach (which is great on my iMac!)
>Perhaps it would be a good idea to add a battery mode option in the Project Dashboard to switch to the settings outlined in that article automatically?
I think so.
IK: ... processor-power hungry app when run with the full features set deployed
Which features exactly are power hungry, and can you do without them? For instance, the Automatic Workflow is power hungry, but you can solve that problem in part with Pretranslation/Preliminary Whatever. I can imagine Auto-Complete is power hungry, but if you use AA, you may be able to disable it. More?
> Would the storage of project and TM segments in a DB make CafeTran less battery hungry?
Maybe yes but that method would reduce CT to a basic, static and not-so-rapid CAT.
cafetran.training: Though I realise that that would probably imply a complete redesign of CafeTran's RAM based approach
No, not if you use Recall Segments.
>Maybe yes but that method would reduce CT to a basic, static and not-so-rapid CAT.
That's indeed what I assumed. And I cannot comment on the amount of development work. But perhaps (perhaps!) it would be an interesting mode.
One (perhaps interesting) observation: Déjà Vu and memoQ are database-based, whereas Studio loads all XLIFF files in RAM. The first two are much faster in tasks like setting all segments to a certain status. Don't know if that's relevant here ;).
>>cafetran.training: Though I realise that that would probably imply a complete redesign of CafeTran's RAM based approach
>No, not if you use Recall Segments.
But that's only limited to the retrieval phase, not to the storage of segments during the translation project.
> Which features exactly are power hungry,
The ones I listed in that article. As for auto-completion/prediction, you might want to experiment with it by turning it off/on but I would not turn off this feature as it is such a time-saver.
cafetran.training: But that's only limited to the retrieval phase, not to the storage of segments during the translation project.
It's the retrieval phase that matters. Storing finished segments can't possibly be the problem.