Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: st: RE: Slowing Stata down
From
Laura Gibbons <[email protected]>
To
[email protected]
Subject
RE: st: RE: Slowing Stata down
Date
Wed, 22 Feb 2012 14:23:58 -0800 (PST)
I have Stata SE, but I did find another work-around, which was to change
the working directory (and data) to a flash drive.
Thanks, everyone, I think I'm set. It doesn't sound like this is a
wide-spread problem.
On Wed, 22 Feb 2012, David Radwin wrote:
Laura,
If you have Stata/MP, you could reduce the number of processors it uses by
using -set processor-.
See http://www.stata.com/statalist/archive/2009-07/msg01281.html
David
--
David Radwin
Research Associate
MPR Associates, Inc.
2150 Shattuck Ave., Suite 800
Berkeley, CA 94704
Phone: 510-849-4942
Fax: 510-849-0794
www.mprinc.com
-----Original Message-----
From: [email protected] [mailto:owner-
[email protected]] On Behalf Of Laura Gibbons
Sent: Wednesday, February 22, 2012 1:55 PM
To: [email protected]
Subject: Re: st: RE: Slowing Stata down
Sarah,
I only have one Stata instance running, and I only have this problem in
Stata.
When I had this problem last year, Stata support said "I suspect the
problem is that Stata is executing the do-file faster than your machine
can write to disk." Because this was a program I wrote, I could just
add in a few msec of sleep to slow it down.
In -mi reshape-, Stata writes one file per imputation to disc. They are
there when the command dies. So I'm pretty sure that's the problem.
Like you, I'm hesitant to mess with the Stata source code. So far my
workaround is to run this step on a different computer.
thanks,
Laura
On Wed, 22 Feb 2012, Sarah Edgington wrote:
Laura,
Are you running multiple instances of Stata simultaneously? Or maybe
doing
something else to access the file outside of the current instance of
Stata?
This really shouldn't be happening unless multiple processes are
trying
to
access the file at once. Do you have problems with file access in
other
software? Are you on a shared system where someone else could be
accessing
the file? This is very strange behavior and could be an indication of
either a problem with your hardware or your OS. My recommendation
would
be
to figure out what the underlying problem is and fix it, rather than
trying
to work around it in Stata.
I suppose, in theory, you might be able to add a -sleep- command by
creating
your own versions of the mi.ado and mi_cmd_reshape.ado files. That
doesn't
strike me as a particularly good idea, though. Plus, I quickly
glanced
over
the mi_cmd_reshape.ado file and didn't see any evidence of it calling
for
accessing any files on disk. Have you used -set trace on- to figure
out
exactly where the error is being generated? If you decide to try to
work
around the problem within Stata the first step is definitely going to
be
figuring out exactly where the problem is happening.
Hope that helps.
-Sarah
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Laura
Gibbons
Sent: Wednesday, February 22, 2012 11:57 AM
To: [email protected]
Subject: st: Slowing Stata down
My Dell PC computer has timing issues such that when Stata's accessing
a
file on disc, Stata can occasionally go too fast, at least compared to
my
computer, generating error messages about files being "read only". In
my
own code, if I have the program "sleep" for a few msec before
accessing
a
file, I can get around this.
But is there anything I can do to slow down internal Stata code? I'm
trying
to MI reshape a data set, and I get error messages during the
"assembling
results" stage about files being "read only" which I know are
indications of
the same problem. [My computer at home, while generally running
faster,
does not have this problem, either in my other code or within MI
reshape.]
Many thanks,
Laura
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laura E. Gibbons, PhD
General Internal Medicine, University of Washington Box 359780,
Harborview
Medical Center, 325 Ninth Ave, Seattle, WA 98104
phone: 206-744-1842, fax: 206-744-9917,
Office address: 401 Broadway, Suite 5122.7
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laura E. Gibbons, PhD
General Internal Medicine, University of Washington
Box 359780, Harborview Medical Center, 325 Ninth Ave, Seattle, WA 98104
phone: 206-744-1842, fax: 206-744-9917,
Office address: 401 Broadway, Suite 5122.7
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laura E. Gibbons, PhD
General Internal Medicine, University of Washington
Box 359780, Harborview Medical Center, 325 Ninth Ave, Seattle, WA 98104
phone: 206-744-1842, fax: 206-744-9917,
Office address: 401 Broadway, Suite 5122.7
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/