This is a good question. But let's imagine for a moment what will happen if you have a weak system and you get to work a huge file that was created on a powerful 64-bit system ...

You can put the same question against any business tool. What if you have a weak system and you get to work on a huge file that was created on a powerful 64-bit version of Word or Excel? The fact is that if the core architecture of the product was updated to allow for better memory allocation and hyper threading, even lower end systems would see great improvements in the way they interact with the software. In practise, having a faster or slower machine does not make a great deal of difference when working with Studio, and this is the main issue I'm drawing attention to as it is the software itself which is the bottleneck, not the hardware.

For more than 10 years of work, I have never had problems with MS Office documents that caused out of memory exception ... This is not a software performance problem. This is an optimization problem.

I agree. However I have certainly had instances where I have had to work with gigantic Excel files, which would only open when using a 64-bit version of Excel, but crash with out of memory error when using the 32-bit version. 

Not a matter of out of memory exceptions, but a matter of having a whopping load of memory resources available on my computer that SDL cannot access because it is a 32 bit application. So I have a fast system but slow Trados. Not fun.

Of course, I talked about system performance and software optimization.

When you have a fast system and 64-bit trados, others will still have out of memory ecxeption on a slow 32-bit system. It is necessary to put pressure not on the development of the 64-bit version of trados, which is costly, but on the optimization of the 32-bit version.

When you have a fast system and 64-bit trados, others will still have out of memory ecxeption on a slow 32-bit system. It is necessary to put pressure not on the development of the 64-bit version of trados, which is costly, but on the optimization of the 32-bit version.

But there will always be projects with huge TBs/TMs that will make Trados' memory use balloon past 1.5GB and cause the out-of-memory exception! It's a limit on the fact that 32-bit processes cannot access more memory than needed.

TM bases, as far as I know, are sqlite files (I'm not talking about TMX files). I'm not the most advanced developer on .NET, but I dare to suggest that the 32-bit version of Trados Studio may well work with files larger than 2 GB. Again, this is most likely an optimization problem. What the hell, before the developers could fit all the necessary functionality of a few kilobytes of RAM. Now for this you need a few gigabytes)))