Peter: Here are some interesting points that I had observed in my analysis where PerlScript was very much sluggish vis-a-vis JavaScript and VBScript.
The purpose of me doing that was this. The recordset is being given to the ASP Page as I had shown before. However, when the data is presented it has to be in this format: Date\Account Names AMY JOEDOE REXARUL -------------------------------------------------------------------- 2001-10-01 01:00:00 555.234 623.456 772.265 2001-10-01 02:00:00 544.345 689.520 800.002 That is why, I had constructed a HashOfHashOfArray. getDTS() is a function that I wrote that would bind the Database Date which would be in Variant form to a Perl string data type. I figured out, that when using PerlScript with data structures the page took a staggering 13-16 seconds to render, whereas a plain VBScript or JavaScript coded page took a mere 2-3 seconds to render. While trying to nail down the problem of performance, I tried to remove the sort on dates, etc to figure out if that is the bottleneck for the poor performance. But I found that the slashing of data into the HashOfHashOfArray data structure what turned out to be the bottleneck. When I removed that too, and just plainly looped through the recordset from database in Perl, the page rendered around 6 seconds, still much slower as compared to VBScript or JavaScript. In a nutshell, I observed big performance cost when using Perl Data Structures vis-a-vis plain looping processing implemented in VBScript or JavaScript. Thanks, -- Rex -----Original Message----- From: Peter Scott [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 5:33 PM To: Rex Arul Cc: [EMAIL PROTECTED] Subject: Re: Maintaining Order of Keys in a Hash At 05:48 AM 10/23/01 -0400, Rex Arul wrote: >Peter: > >I am not sure how I can differ or accept your statement, which is sort of >appealing to me. Let me run this by you. On querying a database, I am >getting a recordset of this form: > >2001-10-01 01:00:00 Amy 10 20 normal 555.234 >2001-10-01 01:00:00 JoeDoe 15 25 high 623.456 >2001-10-01 01:00:00 RexArul 10 20 high 772.265 >2001-10-01 02:00:00 Amy 10 20 high 544.345 >2001-10-01 02:00:00 JoeDoe 15 25 high 689.52 >2001-10-01 02:00:00 RexArul 10 20 high 800.002 > >As you could see the recordset is sorted by Date-Timestamp first and then by >the user-names second in the database. This is how the recordset is handed >out to my ASP Page. I slash the records into a hash with Date-Timestamp and >user-names being my hash keys (HashOfHashOfArrays): > >Like this: > >$returnHash->{getDTS($objRS->Fields(0)->{Value})}{$objRS->Fields(1)->{Value } >} = > [$objRS->Fields(2)->{Value}, >$objRS->Fields(3)->{Value},$objRS->Fields(4)->{Value},$objRS->Fields(5)->{V a >lue}]; Might read a bit better as { my ($time, $user, @fields) = map $objRS->Fields($_)->{Value}, 0..5; $returnHash->{getDTS($time)}{$user} = \@fields; } >Now as you see the date-timestamp and usernames, both are not going to lose >their already sorted order from the database. Please shed some ideas as to >how this is would be construed as mismodelling. Let me be clear that I wasn't saying that it (mismodelling) was a given in your case... just that in my experience it has been very common (in others). In this case, there is an obvious way to re-sort the data (I take it that getDTS() does something like convert to epoch time). So you can always recover the order with a call to sort() later on. Unless there are a lot of hash keys this is generally okay. However, there's something odd on the face of it with a time being used as a hash key. It's unusual to be handed a time later on and know that it belonged to the set of ones you'd encountered, although I can imagine it happening. More common in my experience is that you're given a time and you need to find the closest record before or after, or you're given a range of times and you need to find the records in between. In which case a hash isn't the right structure; the records should be in an array, since you're going to have to do a linear traversal (absent some clever algorithm for bucket indexing or the like). Also, your data structure only allows you to pull out records for a particular user if you know their timestamps. I don't know whether you would ever want to access all records for a particular user, but if you did, you'd want a hash keyed by username. *If* that were the case, a data structure like this might be better: { my ($time, $user, @fields) = map $objRS->Fields($_)->{value}, 0..5; $time = getDTS($time); push @recs, [ $time, $user, @fields ]; push @{$recbyuser{$user}}, [ $time, @fields ]; } but as I say, it depends entirely on how you want to access the data. Without further information I have no reason to say you are doing it wrongly. >Thanks in advance, >--Rex > >----- Original Message ----- >From: "Peter Scott" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]>; "Rex Arul" <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Tuesday, October 23, 2001 1:45 AM >Subject: Re: Maintaining Order of Keys in a Hash > > > > At 09:52 PM 10/22/01 -0400, Jeff 'japhy' Pinyan wrote: > > >On Oct 22, Rex Arul said: > > > > > > >Without resorting to any additional lists/arrays, how can I maintain >the > > > >order of the keys in a hash? Is there a "package/module" that would >redress > > > >this issue? > > > > > >Tie::IxHash, on CPAN. > > > > It should be said, if you care about the order of the keys in your hash, >it > > is far more likely that you have mismodelled your problem than that you > > need to use IxHash. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
