Object methods suddenly lagging?

RobertK · 01-09-2008, 08:31 PM

Hey all, I need to figure out a way to benchmark object methods and log them somehow. Maybe I have to create an object for this, I dunno. Perhaps I don't even need to do this, but am being dangerous somewhere in my coding.

I need your advice here.

I'm in the finalization stage of turning my hash() function algorithm enumerator (now PHL: the PHP Hash Library) into a fully object oriented library. The intent is for a modular object that you can use to give users the option to use alternate hashes for security during the install process. (Intelligently picking ones that are tough and fast on their server. Just use Hash() after install, not my objects.)

Only one problem:

Not long ago, and with my previous version even, I was getting speeds of roughly 130gb/sec throughput through the hash() function, but now it averages in the tens of MB/sec. I still get this old speed with the previous version. But now, after a number of supposedly trivial changes (ones I don't recall now) the page takes 5-7 times longer to load! This is from 0.8 seconds to roughly 5.3 seconds average. The previous version typically sits at 0.6-0.8 seconds, but the new hashes with each 3 times and used to hit 1 second generation time tops.

I cannot seem to pin down where the slowdown occurs, which is ticking me off. There are a good number of loops in my test page, but they're all lightweight. I suspect that somewhere inside my object(s) (there are 3) there may be a near infinite loop somewhere. Or I just have too many nested loops, though I find they're quite necessary.

What do you suggest? I have attached the source beta so that you can analyze it for yourself. I would have attached the log file(s) but I cannot find them; perhaps someone could help by telling me what to set in PHP.INI for a WAMP system. Any help is appreciated!

(Background colors won't make much sense so long as this issue persists I'm afraid. I had it just right, and was going to continue to tweak it.)

Addendum: Trying to shutdown Apache, it seems to be taking an inordinately long time. Almost 90 seconds, and I have an AMD X2 4800+. I'm looking into that, but I think it may return to this point if I'm doing something subtly wrong in my script. Restarting Apache yields no difference in page test speed, though Apache closes quickly again.

Salathe · 01-09-2008, 11:03 PM

The code available in your other topic (lets call this 'old') generates a page, for me, in roughly 2.x seconds. The test script in your PHL package ('new') generates the page in around 6.x seconds. Since you're running the hashing algorithm three times in the new code, that seems perfectly fine to me. It doesn't seem that the actual times being recorded are different.

I did notice however that your calculations for the outputting of the throughput were a bit screwy (that, or my math is terrible!). The speed values are given as the time in microseconds ($hash->m_fSpeed). We are using a 1MB file, so it takes fSpeed / 1000 seconds to complete the single test. The throughput would be 1 / (fSpeed / 1000) MB/s. So if the test was done in 0.5 microseconds, then the throughput would be 1 / (0.5 / 1000) or 1 / 0.0005 or 2000 MB/s. For GB it's a simple matter of dividing that value by 1024 (to make, 1.95 GB/s).

After applying that logic to the outputting of the throughputs in both the old code and the new, the values displayed are similar across the two tests.

Just so you're clear the code used to output the speed in the new PHL test is:

PHP Code:


			
// Mine

// Mathematically identical to (1.0 / (speed / 1000)) / 1024

number_format((1000.0 / $hash->m_fSpeed) / 1024, 2);

// Yours

number_format((1.0 / $hash->m_fSpeed) / 1024, 2);

You're probably not looking to make changes to your 'old' code but here's the change I made to that:

PHP Code:


			
// Mine

<?php echo number_format((1000 / $info['time']) / 1024, 2); ?>GB/Sec

// Yours

<?= number_format($info['time'], 8); ?>MB/Sec

As you can see, both old and new code calculate the display the speed in the same way now.

To cut a long story short, for me at least the new version using classes doesn't appear to run any slower than expected. Let us know if you still get this issue

RobertK · 01-09-2008, 11:54 PM

Thanks Salathe; I know that took awhile to confirm and all. I really appreciate your help.

I'm not sure my math is completely wrong though.

Quote:

If the optional get_as_float is set to TRUE then a float (in seconds) is returned.

Since microtime() returns the number of seconds the division into 1,000 is wrong. Thus, (1 / fSpeed) will give the speed in MB/Sec which can then be divided by 1024.

Here's the problem:

My first version hashes once, yes, but the minimum time it takes to do the whole series is 0.2 seconds! This means I should see a minimum somewhere of either 1.2 or 0.6 in my new tests. I don't. The minimum is ~4.6 seconds and the max is ~5.5; the average should be a little obvious. The max I get with the old is 1 second, hinting to a maximum range of 2-3 seconds for the new.

Before I made a few edits, I don't remember them (like I already said), my new script gave almost EXACTLY the same data and throughput that the old did. Loading time was only twice the old. Then, one save later, the time truly went into the tank. Turning from a 100% increase to almost 700% worth of increase!

Worse the throughput is in the tank too, which it shouldn't be. For one thing, the old lists gost as having a throughput of 130GB/sec while the new says: 0.02 GB/Sec.

There's a HUGE problem here somewhere, and I can't find it to save my life!

Salathe, can you confirm that on your system that the throughputs of the hashes are near identical? I'm not really worried about the time it takes beyond the fact it is a sign of the throughput drop, typically.

Salathe · 01-10-2008, 01:19 AM

Quote:

Originally Posted by RobertK

Salathe, can you confirm that on your system that the throughputs of the hashes are near identical? I'm not really worried about the time it takes beyond the fact it is a sign of the throughput drop, typically.

I ran both the old and new codes ten times each then averaged the results to get a reasonable impression of times for each test. The results can be found here: http://salathe.googlecode.com/svn/tests/compare.txt

For my tests at least, the new code (the object version) consistently gave very, very slightly faster results but in the grand scheme of things I think it's fair to say that the two test types behave approximately equally with most results being within a couple of microseconds of each other.

RobertK · 01-10-2008, 01:24 PM

Thanks for your help, that's the result that I feared.

Okay, I don't have the time yet, but I'm going to upload it to my webserver and try it there. I've been working on a localhost WAMP, and I sincerely hope it's just my PHP configuration. Maybe it's the Zend Optimizer? It's set to level 15, and I don't have a clue what that means.

I only wish that I understood what I changed. So that I could avoid it next time.

Anyway, was what I wrote readable and relatively well designed? I'm interested in your critique since it's the first library I've put together in an object oriented fashion.

RobertK · 01-10-2008, 10:16 PM

Okay, scratch that, I rewrote the objects to disregard averaging and just hash a 512KB file. I can still do the math. Well, the throughput signs are much better now (they're automatically converted in the class instead of the display now) and I've done a ton of tweaking elsewhere.

I'm still not entirely sure what went wrong and where, but I do know that MD2 can take as much as 800ms to hash a 1MB file.

Thanks for all the help, I'm good to go.

Wildhoney · 01-11-2008, 02:48 AM

What is the official reason for MD2 being so slow? And how is that speed in relation to MD3, MD4 and MD5?

RobertK · 01-11-2008, 12:21 PM

Uh... the relation is like so:

Code:

md2    3.43mb/sec
md4  200.00mb/sec
md5  180.00mb/sec

(Ratio-type estimation, don't remember exact figures this morning.) But it is that drastic a difference.

I don't have MD3 in my system so I can't test it. However none of the md* series is secure anymore. If your hacker knows what they're doing, and they get ahold of your passwords they can do a collision generation in a second or two.

I don't precisely know why MD2 is so slow, perhaps age, implementation, and (lack of) optimization.

Wildhoney · 01-11-2008, 01:11 PM

I realise MD5 has been dropped as a military grade algorithm, and that SHA-1, although SHA-256 and SHA-512 are preferred, have been adopted.

RobertK · 01-11-2008, 01:38 PM

SHA-1 has a few risks now too, I think there's a collision attack probable now but not much is known publicly. That, or I just couldn't find anything more than an allusion to it.