You are currently working on UAT 

  • Replies 6 replies
  • Subscribers 429 subscribers
  • Views 2280 views
  • Users 0 members are here
Options
Related

Problems editing large files

Bruce Campbell

I know that this has been discussed before, but I want to once again describe what happens when I edit large files, or a collection of files.

Everything is generally all right unless I try to filter on a group of segments. Sometimes it works, sometimes it doesn't. I am not sure why. If I am going to use the filter, I save the file first -- just in case.

I avoid filtering "Translated" segments like the plague.

I forgot today, and used a Dragon command to select the translated segments in the files I was editing. Just after the command came out of my mouth I realised it was a mistake, but it was already too late.

At 12:14, my entire computer locked up. The cursor showed as an hourglass. The cursor did not move in response to the mouse. I could not use Alt-Tab to switch windows. I could not use Ctrl-Shift-Esc to start the Task Manager. Out of desperation (probably does not work in Windows) I tried Ctrl-Alt-Del, but it did nothing. The only thing giving me hope was that the clock on the taskbar was still faithfully updating the time.

So all I could do was wait, or power down my computer, which is an awful thing to contemplate.

At 12:20, the Studio window was accessible again. I tried to click the diskette icon on the window bar to save my files. Studio locked up again, and I thought it might be because Dragon had resumed executing the macro.

At 12:22, I was able to use the mouse, so I tried exiting from Dragon. No problem exiting from Dragon, so it probably was no longer executing the macro. I concluded that Studio froze again at 12:20 simply because I clicked the save icon.

At 12:26, a Studio dialogue showed that Studio had started saving the files.

At 12:42, the save dialogue disappeared and the hourglass no longer appeared when I moved the mouse over the Studio window.

I then tried to close the Studio window, but simply clicking on the menu bar locked the window up again. Studio was unresponsive, the hourglass showed when I moved the mouse over the window.

At 12:51, Studio became responsive again. I tried to close the window again, this time by clicking on the icon in the top left corner of the window, but the window froze again.

At 12:59, Studio became responsive again. I thought I would be sneaky this time and just use Alt-Tab to activate the window and then Ctrl-W to close it.

Unfortunately, just using Alt-Tab to activate the Studio window made Studio unresponsive again.

At 1:01, I used the Task Manager to terminate the Studio process. Just in case, I then did a repair of Studio.

Total time wasted: more than three-quarters of an hour.

I know SDL has no intention of updating the UI, but is it possible to put in timers to gracefully terminate what Studio is doing if it spins its wheels like this?

That way SDL would also have an indication of whether this is a widespread problem, since they would receive an error report. (After all, SDL is not currently receiving any information that anything is wrong, since no error is being tripped.)

I also know that the answer to the above question is most likely "no", but I guess I just wanted to rant a bit about this problem.

Best regards,
Bruce Campbell
ASAP Language Services
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents

  • I'm wondering why didn't you simply wait and let Studio do its thing...
    You already know that large files make Studio extremely slow and you already know that although Studio becomes unresponsive, it's still actually doing its thing.

    This terrible slowness is obviously caused by the entire SDLXLIFF document object being loaded in memory (and most probably in a rather ineffective structure and/or processed using a very ineffective loops, or something similar)... but we already know that although its UI does not respond, its internal processes still work (in most cases).

    And I believe that we also already know that in situations when Studio becomes so unresponsive it's necessary to not perform ANY additional actions like switching Studio views or system windows, etc. as this only "adds more tasks to the processor's queue". This is the only and fastest way out of the situation.

    In any case, I fully agree with you that this is terrible and that it gives the impression that Studio is actually not used internally by SDL for any "serious" tasks, i.e. something bigger than few-pages-long Word files.
  • in reply to Evzen Polenka
    Hi Evzen,

    I actually did wait for Studio to "do its thing..." I had no choice.

    As soon as it became responsive again, after 6 minutes, I clicked the file save icon, which caused it to spin its wheels for another 22 minutes before the files were finally saved. I should have saved the files before trying to filter segments.

    I then tried to close Studio gracefully by using the menu (i.e. File->Exit), but just clicking the menu caused Studio to spin its wheels for another 9 minutes.

    I then tried to close Studio by clicking the icon at the top left of the window, but clicking the icon caused Studio to spin its wheels for another 8 minutes.

    Then I thought I would try avoiding clicking the window at all by using Alt-Tab followed by Ctrl-W, but using Alt-Tab to activate the window caused Studio to spin its wheels again.

    After that I decided to kill the process. At least I was able to save my files, which is all that really matters. The rest was a learning experience showing how futile it is to expect Studio to calm down again after having one of these episodes ;-)
  • in reply to Bruce Campbell
    I am curious why you think that switching windows or doing other things while waiting for Studio would extend the wait time? Studio is only using one of the cores. Seven more to do other things while waiting ...

    And I agree with your assessment that Studio is probably written inefficiently and crawling through an inefficient data structure, and on top of that trying to make do with limited memory because it is a 32bit process, which makes me doubt that recoding the UI would change much. The problem is deeper.
  • in reply to Bruce Campbell

    Bruce Campbell said:
    I actually did wait for Studio to "do its thing..." I had no choice.

    I meant at the and of the whole story when you actually killed Studio.
    But I see now your point - you had your file saved, so not much to lose (apart from risking corrupted project files, Studio settings, etc. ;-) )

    Bruce Campbell said:
    I am curious why you think that switching windows or doing other things while waiting for Studio would extend the wait time?

    It's just my experience with such situations (not only related to Studio). Letting the computer alone is the best thing to do, regardless of all the "one core does this, many others are free to do other stuff" theories ;-). They are just theories, the real life is a real life... ;-)
Reply
  • in reply to Bruce Campbell

    Bruce Campbell said:
    I actually did wait for Studio to "do its thing..." I had no choice.

    I meant at the and of the whole story when you actually killed Studio.
    But I see now your point - you had your file saved, so not much to lose (apart from risking corrupted project files, Studio settings, etc. ;-) )

    Bruce Campbell said:
    I am curious why you think that switching windows or doing other things while waiting for Studio would extend the wait time?

    It's just my experience with such situations (not only related to Studio). Letting the computer alone is the best thing to do, regardless of all the "one core does this, many others are free to do other stuff" theories ;-). They are just theories, the real life is a real life... ;-)
Children
No Data