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?
Hi, for me (MB Pro 2018), the key was really to use the the metal look and not the Mac OS look!
The difference in energy use (and surface temperature) is huge!!
Thanks a lot
Please see the solution in the following thread: https://cafetran.freshdesk.com/discussions/topics/6000048723
and the new tip in the article here.
and it makes no real difference on my MacBookPro, under El Capitan.
The only way to use less CPU here is to minimize CT. Than it drops from around 15% or 16% to below 2%. Not very pratical though :D
During my "stress test" I made a mistake and F/R in my TM instead of in my project :). That really got my MacBook Pro working:
Repeated the test on my MacBook Pro 13" with 16 GB RAM, Core i7:
The idle processor load for CafeTran dropped to 2% after setting both Xms and Xmx values to:
On the Energy tab in the Activity Monitor, CafeTran only takes a few precent.
Using a fresh CafeTran, default settings, except for the values above.
I did some tests on my Mac Mini machine and the idle processor load for CafeTran dropped from around 10% to 2% after setting both Xms and Xmx values the same. For example:
Shouldn't you set both the Xms and Xmx values to the same amount?
I have set the Xmx value to 4GB but it has had no noticeable impact. The CPU usage went down by an average of about 1% (i.e. still 12-13% when idle).
>The idea is to increase the Xms value such as it is the same as Xmx value (to -Xms2048m in the above example). This should reduce the Java memory management cycles called Garbage Collection) and thus relieve the processor.
Is this a mental note to self or a clear instruction to those victims of too hot to handle?
> The culprit may be the high initial Java memory heap size (-Xms) value set for CafeTran.
I should rather say the low initial Java memory heap size. There is a Info.plist file inside CafeTran.app package which contains those values like this:
The idea is to increase the Xms value such as it is the same as Xmx value (to -Xms2048m in the above example). This should reduce the Java memory management cycles called Garbage Collection) and thus relieve the processor.
>I won't indulge in fanciful (though interesting) discussions about re-writing the whole software or anything like that.
We have a special forum for that :).
>This idea is similar to the one you suggested the other day to rewrite CT in Apple's own language (Swift). This would basically mean to write another CAT.
Yeah, I'm great in creating extra work for others.
Not to mention all the needless extra work that I create for myself :).
Like this morning, with this nice Trojan. Brrrrrr