I haven't done any meaningful testing between the releases and have no real
numbers to offer, sorry.
I have read Jarek Miszczyk & Gene Cobb's Expression Evaluators paper in
which they quote their numbers anywhere between 10-90% improvement. They
explain changes well and I am certain they are positive from performance
standpoint, as I know how inefficiently they used to be implemented.

Regardless of the improvements, performance of built-in functions will
always be far superior to anything you or I write. That's because built-ins
aren't really UDFs in a user sense of the word and are implemented in SLIC.
We're talking many orders of magnitude faster.

HTH, Elvis

2007 System i Fall Technical Conference | Orlando | November 4-7
Celebrating 10-Years of SQL Performance Excellence on IBM i5/OS and OS/400

-----Original Message-----
Subject: Stored Procedure Performance on V5R4

Looking for real word examples...

We are on V5R4 and I've heard lots about V5R4's enhanced code-generation
engine for SQL stored procs that is supposed to have taken care of the
earlier issues with SP's. In the past, throwing building strings and
throwing dynamic SQL at the 400 has been noticibly faster than trying to
implement SP's.

I currently have a very simply search query that needs very fast
performance. The amount of SQL is very, very small... I'm not too worried
about code separation or reusablitly because all of the functionality for
this app is being wrapped in a web service and reusable by other apps that

So, my question becomes... Has anyone thoroughly tested D-SQL vs SP's on
V5R4 and figured out if SP's have finally caught up to or surpassed D-SQL
performance on DB2/400?

Thanks in advance for any input.


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].