XSL prob.

[Dimitre Novatchev]

I am amazed.

I am, too. You did 1 million in 7.6 seconds and Dimitre did 104 thousand in
7.5 seconds, yet his is slightly faster per conversion! That is truly
amazing. But I believe 7.6 * 10^-6 seconds is 7.6 microseconds, which is
0.0076 milliseconds.

Bob Foster

OK Guys,

I was also amazed.

Anyway, if something takes 0.073 milliseconds and is not the most frequently
performed operation, shall we agree that this will not be a cause for a
bottleneck in an application? Or even that an end user will not be able to
perceive the difference between this operation and one that takes 7.6
microseconds?

This was just my point.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Martin Boehm]

You did 1 million in 7.6 seconds and Dimitre did 104
thousand in 7.5 seconds, yet his is slightly faster per conversion!
That is truly amazing.
Owned.

But I believe 7.6 * 10^-6 seconds is 7.6 microseconds, which is
0.0076 milliseconds.

Oops, stupid of me. I am one order of magnitude less amazed. ;-)

Martin

 

[Martin Boehm]

I was also amazed.

Anyway, if something takes 0.073 milliseconds and is not the most
frequently performed operation, shall we agree that this will not be
a cause for a bottleneck in an application?

As this evolved to be an academic kind of discussion - no. ;-)
But in terms of portability, homogeneity of implemetation and common
sense - yes.

Or even that an end user will not be able to perceive the difference
between this operation and one that takes 7.6 microseconds?

Agreed.

Martin

 

[Bob Foster]

Oops, stupid of me. I am one order of magnitude less amazed. ;-)

Easy mistake to make. So your original point was that you thought PHP would
be faster and it was 10 times faster. Point made.

Dimitre responds that if not done very often the difference between 73
microseconds and 7.6 microseconds is insignificant. Point made.

It's good to see some actual numbers in performance discussions! Hats off to
both of you.

Bob Foster

 

[Dimitre Novatchev]

Easy mistake to make. So your original point was that you thought PHP would
be faster and it was 10 times faster. Point made.

Actually with the optimization I reported -- pre-calculating 1970-01-01 as a
Julian day number, the XSLT solution becomes twice faster.

Therefore the PHP to XSLT performance ratio in this case is 4-5 times
faster.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Martin Boehm]

P.S.: Would you mind do post or mail the code you used so I can make
a direct comparison on that? Thanks!

Here it is -- just check (as I did) that the value of count($vNodes)
is 104:

[...code sample...]

For the sake of completeness, I ran the code on my machine, too.

I wrapped the transformation into VB (transformNode method), as it is a
little easier to access the complete time date (e.g. with milliseconds)
from there. I called the Win32 API function GetSystemTime for that
purpose.

1. This solution can be optimized still more by having a constant
for vBase (2440588) and not calculating it every time.

Done.

My input XML had 10.000 <timestamp> elements, and the XSL loop took 407
ms.
That breaks down to 0.0407 milliseconds per conversion.

0.041 milliseconds for one conversion

That is, 24570 converstions per second.

24390 conversions per second.

So, the 100 MHz my machine is faster make for an actual performance
increase of merely 0.74 percent. Or zero, in case you rounded the single
conversion time.

q.e.d.

Martin

 

[Dimitre Novatchev]

Thanks. This matches exactly my timings.

Should I say that I enjoyed this dialog )


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

P.S.: Would you mind do post or mail the code you used so I can make
a direct comparison on that? Thanks!

Here it is -- just check (as I did) that the value of count($vNodes)
is 104:

[...code sample...]

For the sake of completeness, I ran the code on my machine, too.

I wrapped the transformation into VB (transformNode method), as it is a
little easier to access the complete time date (e.g. with milliseconds)
from there. I called the Win32 API function GetSystemTime for that
purpose.

1. This solution can be optimized still more by having a constant
for vBase (2440588) and not calculating it every time.

Done.

My input XML had 10.000 <timestamp> elements, and the XSL loop took 407
ms.
That breaks down to 0.0407 milliseconds per conversion.

0.041 milliseconds for one conversion

That is, 24570 converstions per second.

24390 conversions per second.

So, the 100 MHz my machine is faster make for an actual performance
increase of merely 0.74 percent. Or zero, in case you rounded the single
conversion time.

q.e.d.

Martin

 

[Martin Boehm]

Should I say that I enjoyed this dialog )

Me, too. And I learned a lot.

Thanks,

Martin

 

[Bob Foster]

Actually with the optimization I reported -- pre-calculating 1970-01-01 as a
Julian day number, the XSLT solution becomes twice faster.

Therefore the PHP to XSLT performance ratio in this case is 4-5 times
faster.

My hat is always off to you. I'm continually amazed at what you can squeeze
out of XSLT.

Bob Foster

 

[Dimitre Novatchev]

My hat is always off to you. I'm continually amazed at what you can squeeze
out of XSLT.

Bob Foster

In this case our hats should be off to

Marrow,

who is the author of datetime_lib.xsl.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL