help-octave
[Top][All Lists]
Advanced

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

Re: Plotting with 3.2.0 on Windows is SLOOOOOOWWWW


From: Tatsuro MATSUOKA
Subject: Re: Plotting with 3.2.0 on Windows is SLOOOOOOWWWW
Date: Mon, 3 Aug 2009 18:15:50 +0900 (JST)

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/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]