in reply to Re^5: Use more threads.
in thread Use more threads.

This starts 100 threads in < 1/2 a second:

#! perl -slw
use strict;
use Time::HiRes qw[ time ];
use threads stack_size => 4096;

my $start = time;
async {
    #printf "%u starting\n", threads->tid;
    sleep 1e3
} ->detach for 1 .. 100;

printf "Took %f seconds\n", time() - $start;

__END__
C:\test>junk
Took 0.445518 seconds

[download]

Those are do nothing threads, but still, you must be doing something weird. Post your code.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.

Replies are listed 'Best First'.
Re^7: Use more threads.
by password (Beadle) on Apr 30, 2013 at 11:00 UTC

    I just used your code, it took 1.37 seconds. Then I added 9 lines of "use Modules" after "use strict" and now it takes 12.3 seconds:

    use Socket;
use IO::Socket;
use DBI;
use DBD::mysql;
use Tk;
use Tk::JPEG;
use Tk::Table;
use Tk::ProgressBarPlus;
use LWP::UserAgent;

    [download]

    Adding "use LWP::UserAgent;" alone makes it run for over 5 seconds.

    The complete code:

    #! perl -slw
use strict;

use Socket;
use IO::Socket;
use DBI;
use DBD::mysql;
use Tk;
use Tk::JPEG;
use Tk::Table;
use Tk::ProgressBarPlus;
use LWP::UserAgent;

use Time::HiRes qw[ time ];
use threads stack_size => 4096;

my $start = time;
async {
    #printf "%u starting\n", threads->tid;
    sleep 1e3
} ->detach for 1 .. 100;

printf "Took %f seconds\n", time() - $start;

    [download]
[reply]
[d/l]
[select]

      Simple. Don't load everything into every thread.

      1. Tk isn't threadsafe so it has no business being loaded by more than 1 thread -- preferably the main thread -- so don't use it at the top of the code, require your TK::* modules after you've created your pool of threads.
      2. Likewise, it doesn't make much sense to have DBI/DBD modules in multiple threads. The DB server will serialise the accesses from the multiple threads anyway, with the result that queries and stores will be conflicting within the server and slowing each other down. So serialise it at your end. Start a dedicated DBI thread and queue your accesses to it.

      Those two steps alone cut the load time by half on my machine:

      C:\test>junk rem As your posted it.
Took 4.529284 seconds

C:\test>junk rem Tk required after threads started.
Took 3.111319 seconds

C:\test>junk rem DBI/DBD moved to separate thread.
Took 2.166010 seconds

      [download]

      And that is (probably) only the tip of the iceberg. With proper sight of your real code, there are probably lots more simple steps that could be done to improve things no end.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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]
[d/l]

In Section Meditations