Re: Improving SQL speed

Not necessarily speed tips, but some style thing.

Kudos on using prepare / execute.
Instead of ->execute($var[0], $var[1], ...), why not just use ->execute(@var); or ->execute(@var[0..6]);?
Unless I am missing something elsewhere, I don't see what DIE is. Did you perhaps mean die?
Look into the use of my and scoping your variables in as small of a scope as needed. $mp3 as an example should be declared at the point where the new() call is made (eg: my $mp3=MP3::Tag->new(..)).
While the if (/\.mp3$/i) { is ok, you can avoid a level of nesting by changing the enclosing if block to return unless /\.mp3$/i;. My statement becomes invalid if you wish to do something else if it does not end in mp3.
The section where you declare @songinfo, $mp3, and @dirs is wonky. They are mixed types, and I don't think that it does what you think it does (but I could be wrong ;-)

--MidLifeXis

Comment on Re: Improving SQL speed Select or Download Code

Replies are listed 'Best First'.
Re^2: Improving SQL speed by Mad_Mac (Beadle) on Nov 02, 2009 at 08:22 UTC
Thanks. Appreciate the tips.	[reply]
Re^2: Improving SQL speed by Mad_Mac (Beadle) on Nov 02, 2009 at 18:57 UTC
OK, so I worked through your suggestions: Thanks Got it. I was trying to be explicit in the debugging phase, but now that it's working I changed it per your suggestion. OK. I had them declared early on becuase I thought I was getting an error declaring them within the sub-function, but apparently not. I changed them as you recommended and it works fine. Thanks! Can the same trick be used on `if (exists $mp3->{ID3v1}) {`? Yea, Part of that is because I kept changing the way I wanted to use those variables as my code evolved ... part of it's because I've only been working in Perl again for a few weeks after a 10+ year hiatus, and part of it's becuase I occasionally get warnings from Perl that calling certain array variables like `@songinfo[0]` would be better referenced as `$songinfo[0]`. Which makes me think I don't really understand Perl variables yet. So I just keep mucking with it (and plagiarizing other peoples code) 'till it does what I want. After making the changes you suggested, the code seems to be ~10% faster, but I'm not sure. I'm going to add a timer and run it the old way and with your changes. We'll see. Thanks again for your suggestions. Mad Mac	[reply] [d/l] [select]
Re^3: Improving SQL speed by MidLifeXis (Monsignor) on Nov 02, 2009 at 21:03 UTC
Any speed improvement is unintentional. My suggestions were purely for maintenance and readability (speaking Perl, in effect). If it is faster, I take cookies ;-) --MidLifeXis	[reply]