"Do-file Editor" locks up while script is executing

[Tahlor Bolding]

I've noticed that the native "Do-file Editor" (and the rest of the Stata interface) often locks up when Stata is performing some resource intensive operation. Is this really necessary?

I could use another text editor, but I like the "Do-file Editor" tight integration (e.g. shortcut keys, each window is tied to a specific Stata session) and the project manager.

[Nick Cox]

Suppose you could change the contents while it was executing. What would you like Stata to do, use what you first submitted, or your second, third, ... thoughts? Tight integration comes at a cost, and it's this.

(Please use full real names here, essentially given name and family name: please see FAQ Advice on how to change.)

[Tahlor Bolding]

I'm a little confused by what you mean. Presently, I can modify the script in the "Do-file editor" while the script is running. I think the way Stata runs a temp .do file for a script that has not been saved is appropriate; likewise, I think it's fine the "Do-file editor"prevent saving down changes while the script is running.

The problem is rather that it's not practical to use the "Do-file editor" when the script is running, because every time Stata performs some resource intensive operation (e.g. loads a large dataset), all of Stata effectively freezes, or the lag renders it almost unusable. I guess I'm just surprised if it's the case that Stata can't somehow allocate resources such that the "Do-file editor" runs without interruption while a script is running. This applies to the "Command window" as well.

[Sergiy Radyakin]

The behavior may be version dependent. An example where Stata 13 Windows is freezing the do editor is the following:

window stopbox note "Test"
display "Done!"

As long as the message is displayed on the screen, switching to other tabs (e.g. to update the readme : ) is not possible.

For the same reason that Stata is running an already saved do file, I don't see the reason to block the changes in editor. Blocking the changes would make sense if Stata could give some feedback, like "syntax error in line 25", but it doesn't do that.

A long time ago I have reported a collision error where a do-editor was trying to save to a tempfile while that temp file was still running. Perhaps freezing the editor at some moments was a solution taken by Stata developers to prevent that error from happening. Blocking the Do/Run buttons instead would be preferable.

Best, Sergiy Radyakin.

[Joe Canner]

Tahlor,

I have experienced the situation you refer to when loading large data sets into memory, but I have never pursued bringing it to Stata's attention because I assumed it was a system-specific problem that they wouldn't be able to replicate.

Nick & Sergiy,

Based on my experience (assuming Tahlor and I are experiencing the same thing), this is a transitory, performance-related issue, not a situation where Stata is preventing the user from editing a do-file. I have frequently encountered a "Sharing Error" when trying to save a do-file while the do-file is still being executed, but this is something different: it appears as though the system cannot think about any other tasks, even editing a do-file, while loading large files into memory. It's hard to tell whether this is a Stata problem or a Windows problem. I am using Stata 14 MP8 on a system with 256 GB of RAM, so I don't think it is a hardware limitation.

Regards,
Joe

[Sergiy Radyakin]

Sharing violation error can be consistently reproduced in Stata 13.0 with the following sequence:

1. Create a new do file with one command: more
2. Do the file
3. When Stata stops with the more condition, Do the file again
4. "Encountered a sharing violation while accessing: ...some temporary file name..."

Note that editing is possible before and after the sharing violation. It appears harmless, though annoying. I believe Stata should disable the Do/Run buttons if it is not ready to do/run a new set of code. I find the above example simplest, but not the only situation when sharing violation occurs.

Best, Sergiy Radyakin

[Tahlor Bolding]

Joe Canner is correct in his characterization of the issue I'm trying to describe. I've confirmed this happens on different system configurations with Windows 7 and Stata 12&13, including when Windows is reporting < 5% CPU/RAM usage (though, to be clear, it seems to be limited to relatively processing-intensive tasks (sorts, collapses, loading data); e.g. when I load a 2 GB dataset, even though the CPU tops out at 4% and the RAM is at < 1%, it still experiences this issue).