Re^4: Our perl/xs/c app is 30% slower with 64bit 5.24.0, than with 32bit 5.8.9. Why?

[Anonymous Monk]

Hm. That's the one I use for profiling C code; and I've found it very effective. Effective to the point of detecting a difference between two identical opcodes where one causes a cache miss and the other doesn't.

Ok, you've inspired me to look at sleepy again. Do you have any tips on using sleepy? Due to it sampling, I assume that the test cases need to run for some time? Any specific compile options I should use?

I isolated some of the code for the memory test case (the 80%+ slow down), and it turns our that the 64bit 5.24 version is much faster than the 32bit 5.8.9 version on basic perl/xs/c object creation/destruction. I need to do more digging.

I've been writing other test cases, and I'm suspecting something in the xs layer.

[BrowserUk]

Do you have any tips on using sleepy?

Once you've narrowed the scope of the possibilities, bracket the suspect code with calls to getc() or similar so that you can attach teh profiler just before the suspect code and stop instrumenting immediately after.

Not so useful if you've no idea where to look; but very useful once you do.

I assume that the test cases need to run for some time?

It kind of depends on the nature of the code; but longer you run in the errant code the more likely things are to stand out.

Any specific compile options I should use?

I use MS compilers rather than gcc, so I'm not familiar with the latters options. However, you should basically stick to the same options you use for your production code. Anything else is just apples and oranges.

[Anonymous Monk]

"Anything else is just apples and oranges." And bananas.