merrymonk has asked for the wisdom of the Perl Monks concerning the following question:

I have a Perl Tk application that writes a number of spreadsheets and can also start another highly
interactive application. I would like the spreadsheet writing to work in the background so that the
interactive process has as much processor time as it can.
I start the interactive process with the commands
    $ppc = Win32::Process::Create(
        $process,
        $command_a,
        $command_b,
        0,
        HIGH_PRIORITY_CLASS,
        '.'
    );

[download]
which are used when a button is pressed.
Also in the excel writing section I have added a number of $mw->update commands ($mw is the name of the top level widget).
This basically works but I would like it to work better.
Therefore the questions are:
1. Am I doing the correct things with PRIORITY setting and ->update()
2. What can I do to allow the interactive process to get more of the processor time;
3. How can make using the processing starting button to react more quickly than it does at the moment;
4. What other steps can I take to achieve my goals?

Replies are listed 'Best First'.
Re: Getting more of the processor time
by BrowserUk (Patriarch) on Jan 07, 2011 at 16:52 UTC
    1. In general it would be better to drop the priority of the background task rather than increasing the priority of the foreground task.

      Perhaps the simplest way to do that would be to have the task immediately restart itself with a lower priority at startup.

    2. If the first process starts with below-normal priority, then when it starts the interactive with normal priority, it will take priority over the background process.
    3. If the Tk app is busy, it won't be responsive to its buttons.

      The best way to improve that is to run the GUI in a separate thread from the heavy processing. Best, but not simple.

    4. That's rather too open a question without knowing a lot more about your application.
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
Re: Getting more of the processor time
by CountZero (Bishop) on Jan 07, 2011 at 16:44 UTC
    And did you check through the Windows Task manager that indeed the priority of the spreadsheet writing is low and that of the interactive application is high?

    Perhaps the system is just too heavily loaded and this slows everything down.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
      some kinds of IO are just slow and blocking (think cdrom spinning up, making everything else non responsive)
[reply]
        Or Windoze deciding to start some internal "housecleaning" and monopolizing your resources.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
Re: Getting more of the processor time
by locked_user sundialsvc4 (Abbot) on Jan 08, 2011 at 17:15 UTC

    Typically, foreground processes require “snappy response-time,” but they (by their nature) actually consume almost no CPU time.   They spend all their time waiting for I/O.

    Background threads, operating at very slightly reduced priority, actually wind up consuming the lion’s share of the available CPU time.   They more or less round-robin among themselves.   But, because of their priority relative to the foreground task, they immediately yield control to the foreground task when necessary, so that those are “snappy.”

    I find that it is most satisfactory when background threads do not do any direct user-interface I/O at all.   They don’t have any sort of message processing queue with the GUI.   So, from the scheduler’s point of view, their requirements are (and they remain) obvious and consistent.   It’s clear what kind of servicing they need to get, and those needs don’t change.

    In my opinion, you should never elevate the priority of any foreground task.   Nor is it necessary to “unduly lower” the priority of a background task.   The OS scheduler will always attempt to keep all CPU’s and all I/O devices as continuously busy as it is possible for them to be.   The priority values, relative to all other priority values of extant processes at any moment in time, are essentially suggestions to that scheduling algorithm.

Back to Seekers of Perl Wisdom