Bookmark and Share

Notice: On March 31, it was announced that Statalist is moving from an email list to a forum. The old list will shut down on April 23, and its replacement, statalist.org is already up and running.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: st: RE: Slowing Stata down


From   "David Radwin" <dradwin@mprinc.com>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: st: RE: Slowing Stata down
Date   Wed, 22 Feb 2012 14:04:33 -0800 (PST)

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: owner-statalist@hsphsun2.harvard.edu [mailto:owner-
> statalist@hsphsun2.harvard.edu] On Behalf Of Laura Gibbons
> Sent: Wednesday, February 22, 2012 1:55 PM
> To: statalist@hsphsun2.harvard.edu
> 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: owner-statalist@hsphsun2.harvard.edu
> > [mailto:owner-statalist@hsphsun2.harvard.edu] On Behalf Of Laura
Gibbons
> > Sent: Wednesday, February 22, 2012 11:57 AM
> > To: statalist@hsphsun2.harvard.edu
> > 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/


© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   Site index