Is there any way to make CreateProcess faster? - Programmer

This is a discussion on Is there any way to make CreateProcess faster? - Programmer ; When starting an application with CreateProcess, there is often a delay of several seconds before it accepts input on stdin. It seems to be most prevalent on the first run, so it is probably a caching issue. Does anybody have ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Is there any way to make CreateProcess faster?

  1. Is there any way to make CreateProcess faster?

    When starting an application with CreateProcess, there is often a delay
    of several seconds before it accepts input on stdin. It seems to be
    most prevalent on the first run, so it is probably a caching issue.

    Does anybody have an idea of how CreateProcess could be made faster? It
    takes a lot of options so there might be some possibility of tweaking,
    but the msdn docs does not seem to offer any info on performance.

    Jarod


  2. Re: Is there any way to make CreateProcess faster?


    jarodcline@gmail.com wrote:
    > When starting an application with CreateProcess, there is often a delay
    > of several seconds before it accepts input on stdin. It seems to be
    > most prevalent on the first run, so it is probably a caching issue.
    >
    > Does anybody have an idea of how CreateProcess could be made faster? It
    > takes a lot of options so there might be some possibility of tweaking,
    > but the msdn docs does not seem to offer any info on performance.
    >
    > Jarod


    I think this is much more the problem of application created than
    CreateProcess function itself. Most likely it is too big and/or uses
    too much .dlls and/or performs a lot of initialization before it starts
    stdin (and data used in initialization are later cached).

    --
    Mirek Fidler
    U++ team leader. http://www.ultimatepp.org


  3. Re: Is there any way to make CreateProcess faster?


    "Mirek Fidler" wrote in message
    news:1168859641.497991.23690@s34g2000cwa.googlegro ups.com...
    >
    > jarodcline@gmail.com wrote:
    >> When starting an application with CreateProcess, there is often a delay
    >> of several seconds before it accepts input on stdin. It seems to be
    >> most prevalent on the first run, so it is probably a caching issue.
    >>
    >> Does anybody have an idea of how CreateProcess could be made faster? It
    >> takes a lot of options so there might be some possibility of tweaking,
    >> but the msdn docs does not seem to offer any info on performance.
    >>
    >> Jarod

    >
    > I think this is much more the problem of application created than
    > CreateProcess function itself. Most likely it is too big and/or uses
    > too much .dlls and/or performs a lot of initialization before it starts
    > stdin (and data used in initialization are later cached).


    Yes, usually started process is the problem.
    If the application needs to be started more than ones every few minutes it
    should be replaced by internal code (or an application that can be
    instructed to do what is needed remotely, eg with DDE or OLE).

    It is well known fact that the slowest thing in Windows is process
    creation.That doesn't mean that CreateProcess itself is to blaim even if
    there may be a few things to improve on speed a little bit. The most obvious
    tweek would be to specify the full path to the EXE and keeping parameters as
    short as possible (if you have control over the startee).

    What takes most time in starting processes is setting up the processor
    itself and the process environment and load the code and data needed. Even
    if EXE is probably in file cache after first run it doesn't reduce the
    initialisation. Of course, it helps if DLL's won't have to be relocated and
    that only pages actually needed in any given situation is loaded at
    startup -- usually memory manager loads pages on demand.

    If your compiler supports it you could also find delayed DLL loading useful.
    You could also, if the startee supports it, start a separate copy of it that
    never ends.

    Anyway, the best solution is multiThreading instead of multiProcessing.

    - Sten



+ Reply to Thread