When is the delay? Is it from 'run the script' until 'window with button opens' (which can be attributed to Tk, but is a delay I've never seen and don't reproduce), or is it from 'click the button' until 'Browser window opens' (which is very likely something specific to your default browser and nothing to do with Perl or Tk)?

BTW, you don't need to require and use the same module - just use use.

What OS/Perl/Browser/Proxies are you running? Cos with Vista/AS1004/Opera/None, the HTML is displayed instantaneously when I click the button if the browser is running and takes (empirically) less than a second if it isn't.

In essence, you should probably look carefully at your particular set-up rather than attributing the problem to Tk.

I'd been seeing the problem on a few workstations, all winXP using activestate's perl (5.8.8) with either Firefox 3.5 or IE 8 as the default browser.

I'd been testing with the browser already open but windows would start it up to load the file if it weren't. For me the slowdown starts as soon the button is clicked. The button itself even stays in a depressed state for almost the entire wait. After seeing that you guys aren't getting the same results I pulled out an old test box (XP with IE 6) and it worked fine on that machine so it looks like the problem might be limited to the workstations.

I originally ruled out browser issues and focused on perl/tk as the source of the trouble because removing the perl/tk lines always fixes the problem and it's easy to blame the thing you least understand, but I'm going to have dig into this a little closer.

This could be a problem with the install on the affected machines or even antivirus/security software related...

Thanks once again for the help and the tips!

I'll let you all know what the trouble was if I manage to track the source of this down to anything more interesting than a bad image or a conflict with some obscure internal application.

You are writing each line separately?
I suggest storing everything you want to write in a variable, and then write it all out in one big I/O operation. The writing process should be faster, and AV/Sec software won't be tempted to rescan the changed file fifty thousand times.

Why are you using Tk merely to create a button?

It seems likely to me that executing this script is not significantly less demanding (of the ultimate user) than it would be to execute a non-GUI script from the command line.

Granted, when you write the code to populate your hashes (rather than hardcoding them), your CLI script will likely need argument(s) [source file(s) and output file] but if the Monks who can answer your actual question conclude that the issue is in some- or large-part the extra overhead of Tk, you're faced with a choice: "to take a hit in performance in exchange for the simple interface" or to offer the user(s) a usage prompt or training.

No, the actual interface isn't just a button. :) If that were the case I'd agree that it wouldn't be worth the trouble. In general I'd rather just run things from the command line which is why this is only my 2nd attempt at using perl/tk. :)

In the actual script none of the data is hard coded. All the input gets put into the interface (text boxes, drop downs etc) and then that data is processed and used to populate the hashes/html table/etc.

None of that extra stuff was a major contributor to the speed problem however, so I kept the perl/tk stuff as simple as possible in my example.

If the speed is all just overhead and there's nothing for it than I'll have to start looking at other options. The problem seems to be output related more than anything. It's strange, but I've noticed that if I write the output to a plain text file and just open it with notepad it does seem a bit faster. I may have to settle with that, but I'd lose a lot in the formatting/spacing department.

Eminently reasonable. Seems sensible!

But your distinction between a plain text file and the .html output of your OP puzzles me again, as any difference should be negligible: the .html source is, to all intents and purposes as far as writing the file is concerned, a "plain text file."

Or does your actual script open a browser after writing the output? That, of course, would add a bit more overhead. In that case, you cantrim the rendering time by assigning width to table and the ten tds.

In any case, it may be useful to profile your actual script: see http://search.cpan.org/~timb/Devel-NYTProf-2.10/lib/Devel/NYTProf.pm.

OTOH, it may be even more useful to await better answers from Tk gurus here.

There is one Tk trick I have heard of that could help as well. The trick is to hide the window, create the rest of the GUI, and then display it. The changes for this are shown below.

#....
my $main = MainWindow->new();

# Add this line to hide the window
$main->withdraw;

$main->title("Button Window");
$main->configure(-background=>'#c0c0c0');
$main->optionAdd('*BorderWidth' => 1);
my $bottom = $main->Frame(-background=>'#c0c0c0')->pack(-expand=>0, -f
+ill=>'both');
my $sub_button=$bottom->Button(-width=>40, -background=>"#c0c0c0", -fg
+=>'black', -text=>'CLICK ME', -font => ['Courier', 10], -command=>\&c
+lick);
$sub_button->pack(-side => "bottom", -anchor => "s", -expand => "n", -
+fill => "none");

# Add these two lines to display the window after you have finished cr
+eating the GUI
$main->deiconify;
$main->raise;

MainLoop();
#...
[download]