http://qs1969.pair.com?node_id=53749

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

Hello All, I'm working on some CGI development in Perl (obviously, heh) and I output _alot_ of html from my perl scripts. I was wondering what the best way to do this is. I can think of the following ways.

1. Use CGI.PM, which I don't have alot of experience with
2. Simply 'print' the html code (ie. print "<table><tr>..")
3. Open html files and print them out

Which of these would yeild the quickest results, if there is a difference at all. When it comes to simply printing the html out does perl take longer to print one long string or many shorter strings.
ie. 
print "<table><tr><td>...</td></tr></table>";

[download]
OR 
print "<table>",
      "<tr>",
      "<td>",
      "...",
      "</td>",
      "</tr>",
      "</table>";

[download]

Thanks for your input.

skeight

Replies are listed 'Best First'.
Re: CGI Benchmarks
by chromatic (Archbishop) on Jan 23, 2001 at 22:39 UTC
    Unless you're printing out megabytes of data, it's not likely to make a difference.

    However, if you disable buffering with $| and print a number of small lines, it will be slower than printing most of a document at once. This, of course, depends on the buffer size of your OS and on such things as packet size. Your web server may also intercept data instead of allowing you to write to a raw socket.

    This is one of the last things I would worry about optimizing. You're more likely to get better speed out of using Fast CGI or mod_perl than you are switching from printing a list to printing a here-doc.

[reply]
(tye)Re: CGI Benchmarks
by tye (Sage) on Jan 23, 2001 at 22:19 UTC 
    print <DATA>;
__END__
<table>...</table>

    [download]

    seems like it might be slightly faster than other alternatives I could think of.

    Usually, optimizing parts that haven't been determined to be a non-trivial part of the total run time is a mistake, though.

            - tye (but my friends call me "Tye")
[reply]
[d/l]
Re: CGI Benchmarks
by Gloom (Monk) on Jan 23, 2001 at 22:20 UTC
    I think you may try something like this : 
    print << "END_OF_HTML";
<HTML>
<BODY>
This work huh ?
</BODY>
</HTML>
END_OF_HTML

    [download]
    It's probably faster, no ? ( The monks will juge )
[reply]
[d/l]
Re: CGI Benchmarks
by arturo (Vicar) on Jan 23, 2001 at 22:27 UTC

    I realize this isn't really an answer to your question, but the printing is a part of your overall algorithm that offers the least gain through optimizing (although I'm sure it's possible to contrive an extremely slow way of printing =).

    If I were you, I'd concentrate on optimizing the parts of your code that process the data. Use the wonderful Benchmark module to test various algorithms (and you can apply that to various ways of printing too).

    Of course, you may already have done that, but what the hey ...

    Philosophy can be made out of anything. Or less -- Jerry A. Fodor

[reply]
Re: CGI Benchmarks
by AgentM (Curate) on Jan 24, 2001 at 00:14 UTC
    Since you specifically mention "lots of HTML", I would shoot for HTML::Template or some other template mechanism. It will keep your perl code separate from your HTML and you'll have cleaner results. Also, Perl won't be forced to parse through worthless HTML (that's what [HTML::Template might chug through later :-D)
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
[reply]
Re: CGI Benchmarks
by gaudior (Pilgrim) on Jan 23, 2001 at 22:53 UTC
    I'm not sure worrying about the speed of printing text is that important. I'd use CGI.pm, and concentrate on the speed of the development process. Clean, readable code, and careful thought for the process will yield better results.
[reply]
Re: CGI Benchmarks
by skeight (Novice) on Jan 24, 2001 at 01:20 UTC
    WOW! Thanks for the quick response everyone! I didn't think I would get so many responses so quickly
    Well, the census seems to basically be, "who cares", since it doesn't take a whole lot of time anyway and that makes sense to me.

    I suppose concentrating on the small amount of DBI I'm doing would help speed up the process a little. (Not that it's slow right now, but hey, there's always room to improve)

    Thanks again everyone!

    skeight
[reply]
Re: CGI Benchmarks
by ColonelPanic (Friar) on Jan 24, 2001 at 04:16 UTC
    I find CGI.pm to be EXTREMELY useful. I use it in every cgi script I write. Particularly, the header() and start_html() routines are great time savers. And it's much easier and safer to handle input from the browser with CGI.pm. Learn how to use it--it's easy and you won't be wasting your time. On the other hand, I often tend to use plain print statements for printing out the html tags in between: 
    I do this:
print "<h1>blah blah blah</h1>";

instead of the CGI.pm way:
print $query->h1(--I'm not even sure of this syntax--);

    [download]
    I don't have anything against the CGI.pm way, but why learn another syntax when I already know HTML? I don't see any particular advantage of the latter way, not even a savings in typing. If I'm missing something here, somebody please tell me.

    When's the last time you used duct tape on a duct? --Larry Wall
[reply]
[d/l]
[select]
      Aaah! But you ARE missing out on something! Using the CGI tag shortcuts you don't have to write out the tags and the string is enclosed in Perl's parentheses rather than difficult to mind-parse tags (stay in Perl if you're using Perl ideology). Also, You'll be able to organize the HTML more clearly- including indentation (automatic for Perl and NOT for HTML in good editors), better spacing, and attribute clarity. Especially if you have long lines of attributes, you'll save yourself days of mind-boggling debugging if you use: 
      print HTMLtag({-attr1=>'bob',
                           -attr2=>'Sammy Snake',
                           ....},
                         'Sammy Snake's Page');

      [download]
      rather than raw HTML. Table generation is also extremely useful in the CGI module, allowing you to logically group your attributes and indent them rather than arbitrary HTML spacing. If you read through the CGI docs, you'll also learn about a cool "design your own tag" which is easily created in the use CGI; line. That way, you can name an arbitrary new tag (which CGI may not support by default) with arbitrary attributes. In short, using CGI to its fullest can only result in beneficial and "easier-on-them-eyes" programming techniques. It definitely worth reading up on. M$ is mentioned in the tutorial. Btw, the syntaxes are to-the-point and rather obvious. 
      print TagWithNoAttrs('Howdy Ho Neighbor!');
print TagWithAttrs({-attr1=>'Blue',-attr2=>'orange'},'How many Preside
+nts does it take to screw an intern?');

      [download]
      CGI also supports a method whereby you simply pass string arguments and thus implicitly print the attributes in a logical order without declaring what they are, but I tend towards the more explicit method. Have fun with CGI, though. That's what its main purpose is. (OK, so maybe that's arguable.)
      AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
[reply]
[d/l]
[select]
        You have a point there. The CGI.pm version does look a lot cleaner. For table generation, also, I would probably look into the module in more depth. However, I disagree with the point about debugging. I find that errors in printing the HTML are almost always readily visible. If an attribute isn't correct, you will instantly notice that that header isn't centered, or whatever. A simple view source will generally pinpoint the problem.

        When's the last time you used duct tape on a duct? --Larry Wall
[reply]
      That is actually the current way that I am doing it, except for the fact that i have "data files" that hold the html.
      ie. 
      open(HTML,"index.da1");
while(<HTML>){print $_;}
close(HTML);

      [download]
      then I'll have whatever dbi stuff I have to do then do the same thing for "index.da2" and so on. Do you think that's slower than just having all the html code "embedded" into the perl?
[reply]
[d/l]
        Sorry I am a bit late on this thread.

        Without seeing the whole context of your example, I am prone to say that you are delving into serious overkill. Why use a Perl script to deliver the contents of a text file without doing anything to it? HTTP is perfectly capable of doing this for you. :) 

        open(HTML,"index.da1");
while(<HTML>){
    # do something to $_
    print $_;
}
close(HTML);

        [download]

        Yes, that is slower than embedding the code, because you have to open a file, as well as print each line. But, if you are actually doing something to each line, or even just a few special lines - then it is a viable solution. Of course, if you are just testing the waters, then that is certainly understandable.

        But that's not my point - database access will make your speed concerns with your current program seem very trivial.

        Which brings me to my real point - "embedding" HTML into a Perl script really only has one major issue in my books - MAINTAINABILITY!!

        If you are the only user of this script, don't worry about it. But, if you are coding for the good of a larger project, one that has HTML content writers and programmers - then you will want to seperate the HTML from the Perl.

        Generally, Perl programmers don't want to have to concern themselves with the details of HTML layout - and HTML writers usually can't understand Perl code.

        My first real assignment after graduating was a Cold Fusion project. My HTML was embedded in the Cold Fusion files like a cancer - and when it came time to tweak the position of this or that graphic, guess who had to do it? Me!! If I was smart, I would have seperated the HTML code completely, so that the HTML writers could tweak without having to be scared that they would screw everything up.

        If you really want to put your HTML code in separate files, look into HTML::Template, it is well worth your time.

        Jeff 

        L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)
[reply]
[d/l]
A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Seekers of Perl Wisdom