| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| ESQL Question? |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqsiuser |
 Posted: Mon Jan 16, 2012 7:34 am Post subject: |
 |
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| fjb_saper wrote: |
And let us not forget the correct use of a reference variable.
If you go "walking the tree" for each loop, the performance of the select (or a loop with reference) can well be over twice as fast... |
Just to get you right: With "walking the tree" you mean walking into the tree ("root.structure.list" and "list.Element[5]"), instead of taking shortcuts ("next sibling").
I'd consider this to be just improper (ESQL) code, which leaves us with (almost) equal performance between SELECT and reference-loop again.
OK: A SELECT (very likely) is performant (probably you can somehow even screw that  ). ESQL can be extremely close (you need to pay attention, which you probably get right if you are an experienced colleague ).
_________________
Just use REFERENCEs |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jan 17, 2012 5:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| fjb_saper wrote: |
And let us not forget the correct use of a reference variable.
If you go "walking the tree" for each loop, the performance of the select (or a loop with reference) can well be over twice as fast... |
Just to get you right: With "walking the tree" you mean walking into the tree ("root.structure.list" and "list.Element[5]"), instead of taking shortcuts ("next sibling"). |
If someone says "walking the tree" to me, I always take that to mean using what you describe as a shortcut.
Note that in WMB, refering to an element by it's index position is the slowest of all methods. Both a WHILE / NEXT SIBLING and a SELECT will outperform that by an increasing margin as the number of elements increases.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Mon Jan 23, 2012 12:56 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
sorry to write again, but there is something important here.
If there is a super-feature of Broker (which made it so successful), then I think it is that you can write (transformation) code in a low level language (ESQL) which is super-performant. ESQL is distinctive for the product (for Broker), it is not just a choice, it is the (experienced) developers choice (for writing transformation code).
This post is about "SELECT vs treewalking", so... there is more: Within ESQL it is about using reference while-loops and treewalking the proper way (when doing message transformation).
The statement (from fjb_saper) was "walking the tree *for each loop*"... which basically points to that when you start using ESQL you typically code (as learned e.g. from Java) the wrong "ESQL"-way with CARDINALITY, list.element[5] and walking into the tree too often (I must admit, I did that also  ). Instead use move first child, next sibling and while lastmove, which is all you need.
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Jan 23, 2012 11:12 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
So I have one thing to add to this interesting discussion, which is that SELECT is a transformation language in its own right. And because a SELECT is a single expression, no matter how big it is, there are several ways we can make it go faster than if you write a loop yourself. The upshot of this is that if you can perform your transformation in a single SELECT it will usually be faster than doing the same transformation in a loop, even if you use REFERENCES etc.
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
