| Pages in topic: < [1 2 3 4] > | MemoQ 2014 R2 very, very slow!?! Thread poster: Neil Ashby
|
|---|
Marianne Eden (X) 
Norway
Local time: 23:54
English to Norwegian
+ ...
| Yes, very slow! | Jun 13, 2015 |
I agree more than a 100%. I have a more a than 20,000 words file
on remote server and it is taking me ages. Yes, where is Kilgray?
I have to consider asking for a postponed deadline for this job......really.
| | | | Marianne Eden (X)
Norway
Local time: 23:54
English to Norwegian
+ ...
| Turn off predictive typing and auto-pick | Jun 13, 2015 |
This helped a bit when working in the one and same segment. All the rest still very slow.
| | | | | Change “Synchronization Behaviour” to manual | Jun 14, 2015 |
This is not a problem within memoQ but a slow connection to the remote server, which is owned by the company you are working for. Kilgray has nothing to do with it. What you can do is change Synchronization Behaviour from Automatic to Manual.
[Edited at 2015-06-14 11:36 GMT]
| | | | Neil Ashby
Spain
Local time: 23:54
Spanish to English
+ ...
TOPIC STARTER | Thanks Epameinonas | Jun 14, 2015 |
Indeed, just this morning memoQ (the program, not Kilgray) informed me of this problem, suggesting to "disable automatic synchronisation with the remote server" or similar wording.
This helps things run faster between segments.
It is always a good idea, especially on big projects, to work on the remote (computer) based project rather than the server project and just synchronise the data when you turn off memoQ at the end of each session. Data is saved on your own hard-d... See more Indeed, just this morning memoQ (the program, not Kilgray) informed me of this problem, suggesting to "disable automatic synchronisation with the remote server" or similar wording.
This helps things run faster between segments.
It is always a good idea, especially on big projects, to work on the remote (computer) based project rather than the server project and just synchronise the data when you turn off memoQ at the end of each session. Data is saved on your own hard-drive all the time, so you won't lose work if there's a crash, power cut or similar disaster. ▲ Collapse
| | |
|
|
|
| we are improving the speed | Jun 16, 2015 |
Hi All,
I just wanted to pitch in here and explain Kilgray's stance regarding memoQ's speed.
There are two situations: you work locally, or you work against a server. If you work against the server, simply the bandwidth can also be an issue, or the server's specification, and unfortunately we are not able to control what computers our customers use. But we are not disputing the fact that memoQ may also be slow in certain operations and we can do something. If you work l... See more Hi All,
I just wanted to pitch in here and explain Kilgray's stance regarding memoQ's speed.
There are two situations: you work locally, or you work against a server. If you work against the server, simply the bandwidth can also be an issue, or the server's specification, and unfortunately we are not able to control what computers our customers use. But we are not disputing the fact that memoQ may also be slow in certain operations and we can do something. If you work locally, and don't use network drives, cloud synced drives, etc., but plain vanilla HDD, memoQ should not be slow (unless you are using it with some strange specifications, e.g. we have seen slowdown when you are using some Trados-migrated TMXes that have huge segments, like 65000 characters for one segment - this is an isolated case though).
The speed and experience are very important for us, therefore at the moment we are optimizing much on this. We moved to a once-a-year release cycle, but we will release new builds that contain some improved functionality or better performance. At the moment we are speeding up for example spell checking, and we are also speeding up predictive typing. You will see this around the end of July. Then we will try and speed up project checkout, the opening of documents, etc. This will come in September or so. However, all this will only make it to the memoQ 2015 release, as these are not bugfixes but improved functionality (practically, speed is often optimizing beyond what would seem logical in programming).
I just wanted to confirm that we hear the concerns and we don't want memoQ to become a mammoth. Contrary to the popular belief that I often hear and then wonder, we are actually not adding a lot of functionality - we are redesigning and improving a certain amount, as we believe memoQ is already quite a comprehensive tool, and the biggest improvement is when more people start using what we are offering today, not if we add more possibilities for the select few. We used to add features, but since we moved to memoQ 2014, we are not really adding a lot of new stuff, but improving on existing functionality.
I hope this explains.
István (Kilgray's CEO) ▲ Collapse
| | | | | It's all Trados fault ;-) | Jun 16, 2015 |
István Lengyel wrote:
... e.g. we have seen slowdown when you are using some Trados-migrated TMXes that have huge segments, like 65000 characters for one segment - this is an isolated case though).
...
But I guess they might have struggled with a segment that large too
Regards
Paul
| | | | Neil Ashby
Spain
Local time: 23:54
Spanish to English
+ ...
TOPIC STARTER | Thanks for responding / listening István | Jun 16, 2015 |
István,
Thanks for replying, let's hope these "non-buggy" problems get ironed out soon (although I'd say that not being able to use a large number of features because of slowness is a major bug, one has to stop and restart the program - that's a bug).
[Edited at 2015-06-16 15:03 GMT]
| | | | | Step in ther right direction | Jun 16, 2015 |
What István said will be done in the coming months is in the right direction, I think.
Let me just point out three issues that will hopefully go away:
- When one double-clicks on a project, the GUI goes crazy and the screen makes some very weird refreshes while the project is opening. This is something that always frightens memoQ beginners and makes them think that a crash is imminent.
- When one right-clicks on an item in a list (a TM or a TB, for example)
... See more What István said will be done in the coming months is in the right direction, I think.
Let me just point out three issues that will hopefully go away:
- When one double-clicks on a project, the GUI goes crazy and the screen makes some very weird refreshes while the project is opening. This is something that always frightens memoQ beginners and makes them think that a crash is imminent.
- When one right-clicks on an item in a list (a TM or a TB, for example) and selects "View/Edit", it's not this item that opens, but a different one – the one that was highlighted in the list. In other words, right-clicking does not change the selection.
- There is an abundance of dialog boxes. Why show a dialog box with a progress bar when one confirms two or more segments? Doesn't the progress bar belong to the status bar?
Let's wait and see what happens!
[Edited at 2015-06-16 17:33 GMT]
[Edited at 2015-06-16 17:34 GMT] ▲ Collapse
| | |
|
|
|
Marianne Eden (X)
Norway
Local time: 23:54
English to Norwegian
+ ...
| Synchronising mode | Jun 20, 2015 |
I confirm, manual synchronisation solves the problem (at least it did for me).
| | | | | TWB, not Studio | Jun 22, 2015 |
SDL Community wrote: István Lengyel wrote:
... e.g. we have seen slowdown when you are using some Trados-migrated TMXes that have huge segments, like 65000 characters for one segment - this is an isolated case though).
...
But I guess they might have struggled with a segment that large too Regards Paul
Indeed, Paul, but such segment should not exist in real life I believe. We have not seen Studio or SDLX do anything like this, such beasts all come from 2007 and its freaky segmentation. I've actually been pushing for a mini-feature to drop these segments without user warning as you will never be able to reuse them in memoQ anyway.
István
| | | |
I have heard so many wonderful things about MemoQ 2015, so that I decided to give it a try. Specially the Muse feature sounded great.
I might be wrong, but it seems that you have to turn TMX files into MemoQ TMs before your are able to do this. If there is a way to create a Muse directly from a TMX, please let me know.
I started to import my DGT TMX file into a fresh TM. I am doing this on quite a powerful computer. I mean I started it some 15 hours ago and the program is st... See more I have heard so many wonderful things about MemoQ 2015, so that I decided to give it a try. Specially the Muse feature sounded great.
I might be wrong, but it seems that you have to turn TMX files into MemoQ TMs before your are able to do this. If there is a way to create a Muse directly from a TMX, please let me know.
I started to import my DGT TMX file into a fresh TM. I am doing this on quite a powerful computer. I mean I started it some 15 hours ago and the program is still not finished. Yes, my TMX contains about 2.1 million segments - is this a problem? And don't tell me anything about SDL Studio being even slower, in the same time, I created 5 Autosuggest dictionaries from TMX files of the same size on a computer that is less powerful.
My questions are:
Can I produce a Muse directly from a TMX?
What can I do to speed up producing a TM from a TMX file? ▲ Collapse
| | | |
Siegfried Armbruster wrote:
What can I do to speed up producing a TM from a TMX file?
What you could do is split your TMX into four parts and import them separately. In fact, a quarter of your DGT TM may be quite sufficient for the purpose of creating a Muse. Sometimes more isn't better.
| | |
|
|
|
| MemoQ might have same space for improvement | Jul 2, 2015 |
Dominique Pivard wrote:
What you could do is split your TMX into four parts and import them separately. In fact, a quarter of your DGT TM may be quite sufficient for the purpose of creating a Muse. Sometimes more isn't better.
I managed to import the TMX, it only took 33 hours . MemoQ only used 10-20 % of my processor but up to 94% of my 8 GB of memory. The computer more or less froze just handling this import.
I already deleted 1 million duplicate entries from the DGT before I started to import it. I don't see the reason why I should only use 1/4th of the available data and why this should give me the same results? Has anybody reliable data on this?
Funny enough, SDL Studio has no problem handling this amount of data, and is much faster (at least 5 times) processing it. It uses a max of 50% of my processor about 40% of the memory and allowed me to run several other applications in parallel. As I see it, MemoQ might have some space for improvement in this area.
[Edited at 2015-07-02 10:53 GMT]
| | | | Michael Beijer
United Kingdom
Local time: 22:54
Member (2009)
Dutch to English
+ ...
| How about 45 million TUs (only possible w/ a TMLookup SQLite db + CafeTran's "Total Recall" feature) | Jul 2, 2015 |
Siegfried Armbruster wrote:
I have heard so many wonderful things about MemoQ 2015, so that I decided to give it a try. Specially the Muse feature sounded great.
I might be wrong, but it seems that you have to turn TMX files into MemoQ TMs before your are able to do this. If there is a way to create a Muse directly from a TMX, please let me know.
I started to import my DGT TMX file into a fresh TM. I am doing this on quite a powerful computer. I mean I started it some 15 hours ago and the program is still not finished. Yes, my TMX contains about 2.1 million segments - is this a problem? And don't tell me anything about SDL Studio being even slower, in the same time, I created 5 Autosuggest dictionaries from TMX files of the same size on a computer that is less powerful.
My questions are:
Can I produce a Muse directly from a TMX?
What can I do to speed up producing a TM from a TMX file?
You ought to take CafeTran for a spin sometime. Since CafeTran can now open TMLookup databases (which are SQLite dbs) directly since Igor added SQLite to CafeTran's Total Recall feature, I can now scan my massive TMX collection for any matches with every project before starting to translate it in CafeTran.
I used to use memoQ, and even managed to get most of my TMXs into it, over a period of weeks (!), but memoQ just can't work with such large amounts of data without slowing down to a crawl.
Studio, although a bit better at such things, it is also far from perfect.
My TMLookup .db currently contains ... 45,000,000 TUs. Yes, 45 million. And I can run a Total Recall search against it for my CT project in around 1 minute. Sometimes, 2.
Michael
| | | | | Working on it | Jul 2, 2015 |
Michael Beijer wrote:
You ought to take CafeTran for a spin sometime. Since CafeTran can now open TMLookup databases (which are SQLite dbs) directly since Igor added SQLite to CafeTran's Total Recall feature, I can now scan my massive TMX collection for any matches with every project before starting to translate it in CafeTran.
....
My TMLookup .db currently contains ... 45,000,000 TUs. Yes, 45 million. And I can run a Total Recall search against it for my CT project in around 1 minute. Sometimes, 2.
I definitely will. In my opinion the ability to manage and use TMs with several million segments is an absolute must. I really just wanted to try how MemoQ manages these big TMs and I am not really impressed.
| | | | | Pages in topic: < [1 2 3 4] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » MemoQ 2014 R2 very, very slow!?! | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
| | Protemos translation business management system | Create your account in minutes, and start working! 3-month trial for agencies, and free for freelancers!
The system lets you keep client/vendor database, with contacts and rates, manage projects and assign jobs to vendors, issue invoices, track payments, store and manage project files, generate business reports on turnover profit per client/manager etc.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
