Hello , all,

After a remote session with SDL Support, their response is the following.

The speed performance encountered is due to the fact of opening projects and resources remote, thing that generates extra computing power, and has a direct influence on performance. Also, the bigger the project, the longer will be needed to be processed if files are stored remotely.
 
Please find attached the knowledge base article dealing this aspect.
 
Sharing SDL Trados Studio Translation Memories and Termbases On A Network
https://gateway.rws.com/csm?id=kb_article_view&sysparm_article=KB0024742
 
Sharing SDL Trados Studio projects via a network drive
https://gateway.rws.com/csm?id=kb_article_view&sysparm_article=KB0033035

In short, projects can stored in a network drive for backup purposes, but should be opened locally, both TMs/Termbases and project.

Regards
Pavlos

Pavlos Ponos 
Localization Engineer 
Tell the world. 
NLG GmbH 
+30.2310.502.192 ext. 6259 
NLGworldwide.com 
Follow us on LinkedIn | Visit our New Website

But that would mean that your "test" was done in different conditions (like, CU14 with local project, CU15 with network project... or something similar).
If that is true, then your "test" was simply incorrect and the entire report rather irrelevant...

If your test was done in same conditions in both cases, then the SDL Support response would be totally off...

So I'm wondering which of the two is true.

The problem started when we update from CU14 to CU15. 

We didn't change in-between the way we work the projects, so probably something has changed in the way that Studio reads/writes into TMs/Termbases that are saved in a network drive.

Since they don't recommend storing the project in a network drive, for us it's clear, that's why I close this thread.

And the fact that both both articles published after CU15 release, means (?) that the issue introduced to CU15.

Hmmm, hmmm, the main subject of  the articles is something completely different... the main point of them is sharing TMs/TBs, i.e. problems with simultaneous access to databases not actually designed for simultaneous access.
The articles are in fact NOT about any specific performance issues when working with network TMs/TBs! It looks like the support person did not get properly the point! :(

The generic bullshit about network being slower than local drive is pretty irrelevant to the described issue.

Again, for us, the "Sharing projects via network drives is not a supported workflow scenario." is our workflow scenario, and it describes precisely how we handle the projects. So it explains the problems we are facing.

Are you really talking about SHARING, i.e. people working simultaneously on the projects?

If it's about STORING projects on network, then it's a completely different story, totally unrelated to the sentence you quoted.
I worked many years in environment where projects and TMs were stored on a network (logically... so that various engineers can access the project files - at different times! - when they are assigned an engineering task) and - and, logically, there was absolutely no problem with that setup!

Are you really talking about SHARING, i.e. people working simultaneously on the projects?

If it's about STORING projects on network, then it's a completely different story, totally unrelated to the sentence you quoted.
I worked many years in environment where projects and TMs were stored on a network (logically... so that various engineers can access the project files - at different times! - when they are assigned an engineering task) and - and, logically, there was absolutely no problem with that setup!