|
Re: notequal very slow
by Joost (Canon) on Jan 15, 2008 at 16:53 UTC
|
You're either wrong, using something tricky that doesn't show in this example (like lots of symbolic references or tie()d arrays) or the rest of the code is so simple it doesn't do anything useful and you're worrying for no reason at all.
IOW: show more of the code and include the way you've measured the speed of various parts of it.
update: the only thing that I can think off off-hand is that you've got enormous strings of equal length that are identical except for the end. But I'm pretty sure that that is not it.
| [reply] |
|
|
Hi Joost,
Some of the string is indeed very long (almost 40 characters long) but most of the strings being compared is manageable length.
Any magic I can do with perl that will make perl work faster in just that part of the code?
:-)
| [reply] |
|
|
40 characters really isn't very long at all. Especially considering that comparing strings means you generally don't have to check the whole string:
"b1234872938741279834712987398127398712983798123" eq "b2137298379812739812739871239871289379812739817" can be tested to be false after comparing only 2 characters, for example.
In any case, I may be able to help you optimize things, but since I suspect the performance issue is somewhere else in your code you'll have to convince me that your analysis of the problem is correct. Showing that the slowness is in any way significant will help too - It's pointless to spend half an hour speeding up a program that won't take more than a minute of CPU time in its entire useful life :)
| [reply]
[d/l] |
|
|
40 characters is not very long. Thousands or millions might be considered long. Maybe the code inside the if{...} block (not the conditional itself) is the culprit? How are you measuring this?
| [reply]
[d/l] |
Re: notequal very slow
by BrowserUk (Patriarch) on Jan 15, 2008 at 19:42 UTC
|
| [reply] |
|
|
yes that line is inside a loop.
I used a simple print statement to the console, just a line above the statement and that prints very fast. How ever a similar print statement to the console after the not equal statement seems to take a few seconds.
Not sure what to do.
I am pretty sure its correct code...I wouldnt know where to start looking...
| [reply] |
|
|
You need to profile your code. Going by how long print statements seem to take is about as useful as checking wind speed with a wetted finger. For a start, unless you have disabled output buffering, when you see output can be completely unrelated to when your program executed the print statement. In extreme cases, it could be displayed hours later.
The reason for the loops question is that the statement contains two fairly heavily indirected references. In high iteration count tight loops it can make sense to remove invarient parts of such statements from the loop through the use of temporary variables, but without profiling, random tuning is pointless.
It's like trying to improve the performance of your family saloon by polishing the paintwork, whilst ignoring the two hundred weight of junk in the boot and the roof rack.
Grab Devel::Smallprof which will quickly and easily allow you to see exactly where any perfomance bottleneck exist, on a line-by-line basis.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
Cut the code down to just the loop, remove whatever you can, see if it's still slow. if it's not, the problem is in the code you removed. if it's still slow, post the remaining code here.
update: what BrowserUk said, especially the part about output buffering: print statements are not generally a reliable way to measure timing (though you could include the current millisecond time, as given by Time::Hires in your debugging line, which should give you a reasonable indication), but even then, the if(...) statement you posted should probably take a lot less time to execute than printing a line to stdout.
| [reply] |
|
|
| [reply]
[d/l] |
|
|
You could have buffering issues with your print. Did you turn on autoflushing on the handle to you which you print?
| [reply] |