It has been so long now since 64-bit versions of the Windows operating system were introduced, allowing access to more RAM and adding other efficiencies to the systems we use. So imagine my surprise today when, after a recent memoQ build upgrade, all Hell broke loose in the midst of a time-critical project, with crashes every five or ten minutes
Of course all this happened as I was doing a time-critical translation, dictating at top speed to meet a tight deadline for a last-minute legal matter.
So I send a quick cry for help to email@example.com, and in a short while I got a question back, asking whether I was running in 32-bit or 64-bit mode. "What a silly question," I thought. "64-bit, of course!" Wrong, actually.
I don't know why, but it seems that memoQ upgrades are currently configured to run in 32-bit mode. And depending on what kind of work you are doing, that can have unfortunate results. Working with my version of Dragon NaturallySpeaking today it was an absolute disaster that caused me to lose half my working time and sweat buckets right up to the delivery.
There are two executable files for memoQ in the program folder: MemoQ32.exe and MemoQ.exe, the former obviously for 32-bit systems and the latter not-so-obviously for the more typical 64-bit systems for our times.
I checked the properties of the shortcut I use to launch memoQ
and 'shore 'nuff
there was the problem. So I edited the "target" field, which tells the shortcut what to run:
and lived happily ever after for the rest of the afternoon. The worst problems I have seen with a CAT tool for a decade were resolved.
"But how do I know if I have a 32-bit or a 64-bit Windows operating system," you might ask. Good question. Most translators answer this by disemboweling a black chicken and examining its entrails, but being an advocate of better treatment for animals, particularly oppressed chickens, I researched a better way.
The answer can also be found in the Windows Control Panel in the System control. The screenshot from my Windows 7 Ultimate version is shown above; other versions may have a slightly different display, but the System control is where you should look in any case.
P.S. - In my correspondence with Kilgray Support, the engineer helping me had suggested a one-off start of the memoQ.exe application (64-bit memoQ) from the program folder. I thought this was a bit of a hassle, and I questioned why he would propose such a thing and why the 32-bit application would be a default now. I received this response:
" ... this is by design: by default memoQ will start in 32-bit mode to ensure better startup and better user interface performance. But you can start memoQ 2014 R2 or memoQ 2015 in 64-bit mode, which is useful for heavy operations which requires several gigabytes of RAM."
All very well and good... those who do mostly lightweight stuff can go for the default and perhaps have a special shortcut for the "heavy lifting" memoQ version. The problem I see is that most users are not going to know what sucks up a lot of system capacity and may require the 64-bit application.
I suspect that large TMs or other big resources, things like predictive typing (commonly in use) and certainly the use of speech recognition software is going to make a crunch. I am unaware of any discussion (to date) which is publicly accessible, which will make clear the line that is crossed to require more memory access. Most of the professionals I know tend to use memoQ in a rather resource-intensive way, and I am unclear what the recommendations should be here.
P.S. #2 - Kilgray responds to questions on 64-bit versus 32-bit on the Yahoogroups forum: https://groups.yahoo.com/neo/groups/memoQ/conversations/topics/41676. Due to access difficulties with Yahoo's sucky Neo interface, some of the message thread is included here:
I'll try my best to clarify how memoQ relates to 32-bit and 64-bit.
1. Use 64-bit if you expect "heavy" use
memoQ is a "hybrid" application that was designed (at least from maybe version 6) to run in 64-bit mode on a 64-bit system and 32-bit on 32-bit systems. The support for 64-bit mode was added to avoid out of memory issues with "heavy" use, like importing very large documents. (I clearly remember that one of the use cases was importing large FrameMaker documents. Most probably the other most significant use case was memoQ server in general, which, depending on how it is used by how many people, may have to do many things at once and load an enormous amount of resources.)
A 32-bit application is limited to 2 GB of memory regardless of how much memory is available on the system, while a 64-bit application is practically umlimited (technically there is a limit, but it is enormous). One could argue that 2 GB of memory use is not likely in memoQ anyway, but actually there can be short spikes, during document import or when loading a translation memory, for example. There are also further details that complicate this, like memory fragmentation which are frankly too technical for me, but, as far as I understand, they mean that an "out of memory" error is still possible when there seems to be enough memory overall, but not enough "continous" memory for a specific operation.
These kinds of issues are rare in 64-bit operation and more common on 32-bit operation. This means that with 64-bit memory. This means that with 64-bit memoQ you are less likely to get out of memory errors. Use 64-bit memoQ if you expect "heavy" usage or if you have run into out of memroy errors. If you have, the error message displayed by memoQ most probably already advised you to go 64-bit.
2. memoQ is 32-bit is more snappy
Most modules of memoQ are based on the .NET framework and is written in "managed code" that runs under the Common Language Runtime of the .NET Framework. Sorry if this is too technical, but the point is that memoQ itself is (mostly) intermediary code that must be "translated" (compiled) to code that a computer can actually execute, right when the program modules are loaded to memory. The piece of software that does this compilation is called the Just In Time (JIT) compiler. It is the JIT compiler that creates either 64-bit or 32-bit machine code, as required.
The JIT compiler in recent versions of the .NET Framework simply performs way worse when creating 64-bit code than 32-bit code. (Most probably the compilation itself is slower on 64-bit than 32-bit, or it is possible that there are performance issues with the resulting "machine code" itself.) This is a widely known problem, and Kilgray has done elaborate research to confirm that this is why memoQ starts up slower (by approximately 100%) in 64-bit mode than 32-bit mode. It is also likely that some of the interface is also slower in 64-bit than 32-bit. We are also convinced that this was a very signifcant issue to the user base, and has led to unfavourable comparisons to the competition (which I think is at a dubious advantage here in the sense that they don't offer a 64-bit mode, as ar as I know). The good news is that Microsoft has been working on the problem and they have created a brand new JIT compiler for version 4.6 of the .NET Framework. So whenever memoQ gets upgraded to .NET 4.6, 64-bit will see a performance boost.
It is a myth that 64-bit most always perform better, and in the case of .NET (before version 4.6), clearly the opposite is true, at least in terms of loading and "JIT compiling" program modules. This can heavily affect startup times, for example.
I left out the part that is (hopefiully) obvious by now to many of you, and something I have explained here before, maybe twice or more:
As an answer to the performance (especially startup speed) concerns, in recent builds of memoQ, we turned off the autoamtic "hybrid" behaviour that detected the 32 or 64 bitness of the system, and created a separate 32-bit executable (and a start menu/screen shortcut) to start memoQ with. With this you can force memoQ to run in 32-bit mode. This is also the default in the sense that if you just click "memoQ" in your start menu/screen. you start the "forced" 32-bit mode. There is also a "memoQ (x64)" shortcut you can click to enable 64-bit mode on 64-bit systems.
Also, another piece of advice: for users with beefy systems the perforamnce degradation caused by the 64-bit JIT compiler may be completely irrelevant, as memoQ may start up for you in maybe four seconds instead of two. If you have such a machine, 64-bit might be a very good choice. And you get some protection from "out of memory" issues.
Another piece of advice: please don't switch to 64-bit mode if you do not have a beefy system and you are not having any issues with memory use. This might just slow your copy of memoQ down with no benefit in your specific case. Switch to 64-bit if you know you are affected by "out of memory" issues, or you expect some heavy use (very large resources or translatable files, etc).
Message 3 of 3 , Today at 12:49 PM
"It is a myth that 64-bit most always perform better, and in the case of .NET (before version 4.6), clearly the opposite is true"
Really glad that, despite this, Kilgray kept the 64-bit support. The 32-bit version caused out of memory errors for most of our translators after ~15-30 minutes of use, causing a lot of confusion after 2015 hit, until we found the 64bit version :D
Thanks! I switched to 64-bit as per your instructions. I'll let you know when my computer explodes!ReplyDelete
So, here's a curious thing: my Control Panel tells me my OS is 32-bit (Windows 7 Home Premium) but the shortcut I use to launch memoQ points to the 64-bit version. So… which version is running? And do I need to change the target of the shortcut?ReplyDelete
If you have the 32-bit OS then I think you should be running the 32-bit app. You can't access more RAM anyway.Delete
OK, so I guess I should update the shortcut link? (Apologies for my complete ignorance when it comes to this stuff.)Delete
Yes. As shown here, except the other way around: memoQ.exe >> memoQ32.exeDelete
Good catch, Kevin. I have never suspected that MemoQ has a 64-bit support, so I am glad that I came across this post!ReplyDelete
I had the following answer from Kilgray for the same issue:ReplyDelete
Seems that memoQ runs out of the available system resources.
Please close some applications, open the Control Panel / System / Advanced system settings / Performance window, and increase the size of your Paging file.
If this don't help, run memoQ with the following steps:
- If you have a 64 bit Operating System, run memoQ in 64 bit mode with the C:\Program Files (x86)\Kilgray\memoQ-2015\MemoQ.exe file.
- Once memoQ is started open a Windows Task manager, find the MemoQ.exe process on the Details tab, and raise the priority to "High" by right clicking on it.
Thank you, Kevin. This tip solved an issue for me with importing large Word files.ReplyDelete
Last week, I imported a large (50 MB) Word file into MemoQ 2015. It imported OK, but failed to create a preview. After reading your tip, I made sure that MemoQ actually loaded the 64-bit version of MemoQ, then tried the process again. Using 64-bit MemoQ (on a 64 bit machine, of course), MemoQ happily created the preview. So, as you say, for some beefy processes, MemoQ's 64-bit version is the right way to go. (I'm also not noticing any sluggishness with the 64-bit version, either).
The most obvious solutions are often the hardest to come up with ... thanks a million, Kevin, for blogging about this.ReplyDelete
I had performance problems with MemoQ, especially when working with Dragon, and now it all runs smoothly. This week's deadline would have been impossible to keep without this post!
I'm glad this helped, Thomas. I've been reluctant to do posts of this sort lately, because it's discouraging to see how much idiotic misinformation can be found on social media and how often such errors are reinforced by errors propagated by the technology providers themselves.It's like bailing out the ocean with a teaspoon sometimes. But as long as a few decent folk trying to make an independent, ethical living can benefit, it's worthwhile.Delete
do you know it the 64-32 bits question is related to memoQ web search too?
this otherwise very feature sucks my PC more than 5 GB (I have 8 GB) so commonly my PC freezes if I forget to close web search every now and again
Unfortunately, this feature has been plagued with trouble for some time. It used to be that multiple instances of the web search window (Kilgray's mini-browser) would be generated from time to time (almost likethe application forgot there already was one); now I don't see that, but I get the same freezes and crashes if the web search window is open for a while. AFAIK this is due to a memory leak (sloppy programming), and it hasn't been fixed despite the fact that it has been an issue for most of this year. It seems to occur less frequently with me if I close the window after each search instead of just leave it open, but after working for a while I forget it again and... CRASH. Methinks it is time for the development team to focus less on new bells and whistles and more on stability.Delete
Thanks Kevin, I did what you suggested and have had no problems so far!! Much more speedier, thanks again!ReplyDelete
Thanks, it solved my problem, which seems to be related to the web-search window, too.ReplyDelete
The web search window in its current implementation has a serious memory leak, due to a long-unresolved bug in the underlying IE engine. If you don't close it periodically, there is likely to be some trouble. Kilgray Support has explained this in a few channels, but after a few years of this bother, it's probably time for the company to deal with it in some useful way, like an auto-kill above a specified memory usage or a different browser altogether.Delete
Thanks for this! I just started experiencing the "out of memory" issue and this easy-peasy fix solved it straight away.ReplyDelete