I use it on a 64-bit PC and it works allright. I often encounter small issues, but they can generally be solved fairly quickly. There are many other issues that make Trados slow and hard to use with confidence. Not 64-bit PCs. Unless you work on very very large projects.

Glad to read 32 bits are enough and work fine for you, but it is not sufficient for many of us. 

It seems you never see studio suddenly stop working and disappear from your screen in the middle of a doc, with unsaved segments, or do not undergo unavailability times when the autosave functiom runs (which should be a background transparent process, like in, e.g. Word), or have to wait long minutes when performing certain processings on large files or series of files or when accessing to large memories. Most of those issues relate to available RAM, or to its use, which is directly linked to the 32-bits vs 64-bits issue.

With a limited RAM, Studio (like any other RAM intensive software) has to continuously swap data between that limited RAM and your far larger HDs or SSDs, instead of keeping all needed data in its instantly accessible RAM, which, at the end of the day, is a waste of time and can produce errors.

I dream of an update of Studio without any new marginal feature, but with a focus on evolving to 64-bits and fixing some bugs that are still in the landscape after years, such as the index issues when merging 2 segments or hexadecimal characters in a comment that can prevent to reopen a file, which should never occur.

And since we are at the AI era, it could be great to use it for tracking and solving those bugs, rather than dedicate it only to automatic translation.

Glad to read 32 bits are enough and work fine for you, but it is not sufficient for many of us. 

It seems you never see studio suddenly stop working and disappear from your screen in the middle of a doc, with unsaved segments, or do not undergo unavailability times when the autosave functiom runs (which should be a background transparent process, like in, e.g. Word), or have to wait long minutes when performing certain processings on large files or series of files or when accessing to large memories. Most of those issues relate to available RAM, or to its use, which is directly linked to the 32-bits vs 64-bits issue.

With a limited RAM, Studio (like any other RAM intensive software) has to continuously swap data between that limited RAM and your far larger HDs or SSDs, instead of keeping all needed data in its instantly accessible RAM, which, at the end of the day, is a waste of time and can produce errors.

I dream of an update of Studio without any new marginal feature, but with a focus on evolving to 64-bits and fixing some bugs that are still in the landscape after years, such as the index issues when merging 2 segments or hexadecimal characters in a comment that can prevent to reopen a file, which should never occur.

And since we are at the AI era, it could be great to use it for tracking and solving those bugs, rather than dedicate it only to automatic translation.

Hi Philippe,

Have to agree with you on the points you make.

Personally, I find the incredibly slow performance in QA checks with terminology switched on plus the inordinate time it takes to analyze files for a statistics update to be unacceptable.

I have the latest Studio and a PC that game sites rate in the 95th percentile so it's not an old version of Studio or a lame PC that's at fault.

I can confidently bet money on Studio crashing during F8 checks more than half the time. And sudden crashes like that are a clear indication that something major like memory management/access is at fault.

Cheers,

Ed