Hi Neil Allen

There is only a 32 bit version of Trados Studio at the moment.

A 64 bit release is on the backlog and is being considered but there is no timeline as of yet.

Hi Neil,

I think the release of a 64 bit version should be a priority.

My main issue with Studio 2017 is that it gets very slow with big projects, or when I want to go from the Editor View to Project or File view to open another project. It can take from one to two minutes to perform this action. 

My laptop is an i7 with 16 Go of DDR4 RAM, but Studio cannot use them fully as it is a 32-bit application.

This would convince me to upgrade, not a feature like the Tell Me feature, for instance, which targets new users. 

Could you consider to accelerate the release of a 64-bit version of Studio ?

Thank you very much for taking my remark into account.

Hi,
Thank you for your comments, I have added them to the to the Jira task.

Note that Studio is flagged largeaddressaware so can use up to 4GB per running instance. Do you find that you are having issues with projects approaching 4gb, they would be quite large.

If users are hitting the 4gb limit we need to bump the priority.

I am facing the same problem. My machine is 32 GB RAM and i9 Dell XPS but the SDL has crashed 4 times in last 6 hrs. The files are only 60,000 words. Please update the SDL to 64 bit if it stopping it from using it to the fullest specs of the Machine.

The file size should not matter so much, I used to open bigger files in Studio even prior to the current version. Try to exclude other problems like virus scanner, admin rights, file system speed and alike.

Hi,

Same problem for me. Quad Core with hyperthreading, 16 GB RAM, 1 TB SSD disk, I'm full admin.

It's not necessary to reach the 4 GB limit in memory. At about 2,5 GB (as Task Manager says), Trados 2019 raises this error message.
In my own case (an 800 kwords project), I ask Trados to save the project, and it raises the error. Backing to the Edtor view. Close all: "do you want to save... ?" Yes.
It starts it, seems to reach the end, but doesn't complete. Error message and back to the Editor view.
Only solution: "do you want to save ?" No!
All the changes are lost.

The next launch, I expect having the ability to restore intermediate saved files, but none is proposed nor available. Luckilly, the memories are partially saved, and then Ctrl-T, then Enter.
Well, well, well...

One workaround I have found is to monitor the task manager while I work, and, as soon as Trados reaches a little over 2 GB, I save, close everything and relaunch Trados.
What a waste of time! But it seems to work, for a while.

Second workaround: reopened the same project in Trados 2017. This one seems to use less temporary resources than 2019.

As Jerzy Czopik sayd, it doesn't depend on the file sizes. It depends on certains resources managed by Trados.
As the projects grow and grow more, as the features embedded in Trados are growing too, the "step to 64-bit" seems to become essential.
Roll on the 64-bit version!

I wouldn't totally agree with Amit Aryan about using the plain power of the machine (bcs. it's sometimes usefull to have two or more instances of Trados on the same machine), but certainly to go beyond the current limits.

Best regards.

Perhaps someone from SDL Trados could explain why there is not a 64 bit version?

As I seem to recall from my IT days (which admittedly ended a long time ago) it is only a matter of changing a compiler setting in the build process.

So what's so difficult about it, unless I am missing something?

Perhaps someone from SDL Trados could explain why there is not a 64 bit version?

As I seem to recall from my IT days (which admittedly ended a long time ago) it is only a matter of changing a compiler setting in the build process.

So what's so difficult about it, unless I am missing something?

Neil Allen said:

So what's so difficult about it, unless I am missing something?

It's not difficult to do what you have suggested, but simply doing that will not make Studio faster.  It will only allow it to use more memory.  To really optimise Studio the code needs optimising first and these improvements can be obtained while on 32-bit.  The development teams are working on these optimisations but they are not trivial or they would have been completed a long time ago.  Moving to 64-bit may help in some situations when processing very large files, but we really need to address a lot more than this before making this change.

I can't really tell you more than this, as this is all I have gathered from discussions with the teams.  But for sure nobody other than the development team really knows what's involved here and trivialising it doesn't really help anyone.

Paul said:

It's not difficult to do what you have suggested, but simply doing that will not make Studio faster.  It will only allow it to use more memory.  To really optimise Studio the code needs optimising first and these improvements can be obtained while on 32-bit.  The development teams are working on these optimisations but they are not trivial or they would have been completed a long time ago.  Moving to 64-bit may help in some situations when processing very large files, but we really need to address a lot more than this before making this change.

I can't really tell you more than this, as this is all I have gathered from discussions with the teams.  But for sure nobody other than the development team really knows what's involved here and trivialising it doesn't really help anyone.

Dear Paul, point taken.

Seen from that perspective, I suppose the vast majority of all users will not care about 32 or 64 bit. What matters is a stable and reliable software. A software, where all functions work as expected. So I fully agree with you. Before SDL releases Studio 2009 in 64 bit (and I really mean 2009... you certainly understand why), we better let the developers fix the current Studio to be a perfect software.

Ok, thank you Paul. I understand the complexity involved and that if this were so simple it would have been done by now. It is a problem inherent in any large and complex piece of software that has grown in functionality over the years.