I was looking for a CPU consuming loop in the C++ code, but there might actually be some in the script files. Does this help?
*** __gnuplot_get_var__.m~ Tue Jun 9 23:22:14 2009
--- __gnuplot_get_var__.m Mon Aug 3 13:52:35 2009
***************
*** 125,135 ****
fflush (ostream);
str = {};
while (isempty (str))
str = char (fread (istream)');
! if (! isempty (str))
str = regexp (str, "OCTAVE:.*", "match");
str = str{end}(8:end);
endif
fclear (istream);
endwhile
--- 125,137 ----
fflush (ostream);
str = {};
while (isempty (str))
str = char (fread (istream)');
! if (isempty (str))
! sleep(0.05);
! else
str = regexp (str, "OCTAVE:.*", "match");
str = str{end}(8:end);
endif
fclear (istream);
endwhile
On my multicore machine the tic-toc timing is practically the same, but cputime() shows a significant speed-up.
Cheers, Olli
> -----Original Message-----
> From: Tatsuro MATSUOKA [mailto:
[hidden email]]
> Sent: 3. elokuuta 2009 12:16
> To: Saarela Olli
> Cc:
[hidden email]> Subject: Re: Plotting with 3.2.0 on Windows is SLOOOOOOWWWW
>
> Hello
>
> The patch I have cosidered for octave_popen2 in iboctave/losyspep.cc
>
> See
>
>
http://www.nabble.com/Re:-Plotting-with-3.2.0-on-Windows-is-
> SLOOOOOOWWWW-p24766712.html
>
> For the convenience to understand this problem I show the code of
> patched octave_popen2 function.
>
> **********
> pid_t
> octave_popen2 (const std::string& cmd, const string_vector& args, bool
> sync_mode,
> int *fildes, std::string& msg)
> {
> pid_t pid;
> PROCESS_INFORMATION pi;
> STARTUPINFO si;
> std::string command = "\"" + cmd + "\"";
> HANDLE hProcess = GetCurrentProcess(), childRead, childWrite,
> parentRead, parentWrite;
> DWORD pipeMode;
>
> ZeroMemory (&pi, sizeof (pi));
> ZeroMemory (&si, sizeof (si));
> si.cb = sizeof (si);
>
> if (! CreatePipe (&childRead, &parentWrite, 0, 65536) ||
> ! DuplicateHandle (hProcess, childRead, hProcess, &childRead, 0,
> TRUE, DUPLICATE_SAME_ACCESS |
> DUPLICATE_CLOSE_SOURCE))
> {
> msg = "popen2: pipe creation failed";
> return -1;
> }
> if (! CreatePipe (&parentRead, &childWrite, 0, 0) ||
> ! DuplicateHandle (hProcess, childWrite, hProcess, &childWrite,
> 0, TRUE, DUPLICATE_SAME_ACCESS |
> DUPLICATE_CLOSE_SOURCE))
> {
> msg = "popen2: pipe creation failed";
> return -1;
> }
> if (! sync_mode)
> {
> pipeMode = PIPE_NOWAIT;
> SetNamedPipeHandleState (parentRead, &pipeMode, 0, 0);
> }
> fildes[1] = _open_osfhandle (reinterpret_cast<long> (parentRead),
> _O_RDONLY | _O_BINARY);
> fildes[0] = _open_osfhandle (reinterpret_cast<long> (parentWrite),
> _O_WRONLY | _O_BINARY);
> si.dwFlags |= STARTF_USESTDHANDLES;
> si.hStdInput = childRead;
> si.hStdOutput = childWrite;
>
> // Ignore first arg as it is the command
> for (int k=1; k<args.length(); k++)
> command += " \"" + args[k] + "\"";
> OCTAVE_LOCAL_BUFFER (char, c_command, command.length () + 1);
> strcpy (c_command, command.c_str ());
> if (! CreateProcess (0, c_command, 0, 0, TRUE, 0, 0, 0, &si, &pi))
> {
> msg = "popen2: process creation failed";
> return -1;
> }
> SetPriorityClass(pi.hProcess, ABOVE_NORMAL_PRIORITY_CLASS); // added
> line
> pid = pi.dwProcessId;
>
> CloseHandle (childRead);
> CloseHandle (childWrite);
> CloseHandle (pi.hProcess);
> CloseHandle (pi.hThread);
>
> return pid;
> }
> *******************
>
> SetPriorityClass(pi.hProcess, ABOVE_NORMAL_PRIORITY_CLASS); // added
> line
>
> This make the child process has always has the absolute higher priority
> class.
> If the parent process is octave and child process is gnuplot this is
> realistic.
> However in general sense I have an anxiety for this simple patch
>
> Your code is worth to be examined.
>
> Thanks!!
>
> Tatsuro
>
> --- Saarela Olli wrote:
>
> > Hi,
> >
> > > octave-3.2.0 occupied 99% cpu activity and thus I guessed that
> > > the speed gnuplot made slower and thus led to slooooow plotting.
> >
> > Such symptoms can arise if the lack of select() in Windows is worked
> around with something like
> >
> > time_t now = time(NULL);
> > while (time(NULL) < now + timeout) {
> > PeekNamedPipe(read_handle, NULL, 0, NULL, &len, NULL));
> > if (len > 0) // data is available
> > break;
> > }
> >
> > which would consume all available CPU time until the program at the
> other end of the pipe has
> > written something. If this is the case, instead of treating the
> symptoms with changed process
> > priorities you might want to go closer to the root cause by adding a
> short sleep to the code,
> > e.g.,
> >
> > DWORD sleeptime = 1; // 1 millisecond
> > time_t now = time(NULL);
> > while (time(NULL) < now + timeout) {
> > PeekNamedPipe(read_handle, NULL, 0, NULL, &len, NULL));
> > if (len > 0) // data is available
> > break;
> > Sleep(sleeptime);
> > if (sleeptime < 64)
> > sleeptime *= 2;
> > }
> >
> > I don't know my way around Octave's C++ sources and couldn't find
> PeekNamedPipe in them, so I
> > don't really know if this is the case. The actual loop structure (if
> any) could involve calling
> > several functions and instead of PeekNamedPipe can, e.g., call an
> unblocking read. Anyway, I
> > hope this helps debugging.
> >
> > Cheers, Olli
> >
> >
>
>
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
>
http://pr.mail.yahoo.co.jp/toolbar/
_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
