in reply to Speed of Template

Well, have you attempted to determine where the extra overhead seems to be coming from? I don't see why fetchrow_hashref would be killing you, unless your data set is so huge that, during the fetch operations, you effectively slow to a crawl. This is doubtful, however.

Have you tried comparing the results of the same calls using fetchrow_array?

Template is a great tool, but don't buy into it if it's simply because you read so-and-so say that it's the best thing he's ever used. Buy into it if it's going to make your life easier.

That said, I bought. I'm trying it out on a new project at work, and I am pretty pleased with the results. And yes, I'm using the DBI Plugin that comes with it. I found that I was able to wipe out my server when I attempted to do some 250+ SQL commands in one script, but I guess that's to be expected. :) (don't ask, I was just playing around with something to find out if it would)

Is there a marked improvement? I doubt it, at least if you're currently running mod_perl and your scripts use Apache::DBI or even plain ol' DBI. But coming from straight use CGI; and use DBI; stuff, I see improvement.

Update: yes, chromatic has a good point from the DBI book, but I'm going to guess that the point of that statement in the DBI book is related to anyone who wonders why the server mysteriously locks while pulling thousands of rows back for data. (Once again, it was just to see what my limits were :) Jeez.)

ALL HAIL BRAK!!!

Replies are listed 'Best First'.
Re: Re: Speed of Template
by Masem (Monsignor) on Feb 09, 2001 at 17:28 UTC
    Right now, in regards to fetchrow_array vs fetchrow_hashset, I've found that in the past versions of my code, I've been burned by using _array; when I did this part of the db query, I'd want the entire row of data, so I'd just select *, and when down the road the db changed because I added another column or the like, I had to go back and account for this aspect at all times. (I did need only specific elements for a quick lookup, but I put all of these into a utility module for the CGI). With how I've got it now, there's only one place where I need to call this key SQL statement, and thus I might be able to clean up the code enough to use _arrry vs _hashset.

    The other reason that I'd want _hashset is that I'd like to toss some more things into the hash that I get back from it after the db, and as such, I can just take that hash ref from this call and not worrying about creating a new hash until the next row.

    But again, it comes down to the fact that running a query with 1-5 results seems to take as long as a 1000 result one based on how my code is called, so I very much doubt the DB is the bottle neck, and instead Template being the problem. I've made sure to put the template calls outside of the loop (that is, make an array of the hashrefs from above, then let Template handle the for-next'ing it). From chormatic's post, it also suggests that caching of the templates should be going on if the envirnoment is persistent -- while I've folled the mod_perl docs and the like to modify the Apache conf, I don't have an easy way to test if I have created the right persistent environment.

[reply]

      As far as getting the column titles out correctly goes, I'd suggest something along the lines of putting as much of your DBI stuff in a single module (an OO one if you like) as possible. That allows you to 'encapsulate' (love that buzzword) your database code. In that module, or elsewhere, you could use the constant pragma to alias column numbers to memorable tags. You'd only have one place you'd have to change, and you'd get the speed advantages of fetchrow_array over fetchrow_hash.

      e.g. : 

      use constant NAME => 2;
use constant ID => 0;
# ...

my @row = $sth->fetchrow_array;
print "Hi, Bob!\n" if $row[NAME] = 'Robert';

      [download]

      Or some such. Just a thought.

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

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom