| Author |
Message
|
| McueMart |
 Posted: Wed Dec 31, 2014 5:54 am Post subject: Why can't we define null REFERENCEs? |
 |
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
I find myself often 'initialising' REFERENCES to point to an arbitrary tree such as:
DECLARE myRef REFERENCE TO Environment; -- initialise it.
...
...
MOVE myRef TO <Where I actually want it to point to>.
My question is, why doesn't broker allow us to:
DECLARE myRef REFERENCE; (Create a null pointer)
...
...
MOVE myRef TO <Where I actually want it to point to>
I imagine that there is a minor performance gain to be had by doing this , and I cant see any documented or logical reason why this shouldn't be technically possible.
Can anyone shed any light on it? |
|
| Back to top |
|
 |
| shashivarungupta |
| Posted: Sun Jan 04, 2015 6:07 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
I DECLARE the REFERENCE link this..
| Code: |
For Example:
DECLARE env REFERENCE TO OutputRoot.XMLNSC.soapEnv:Envelope; |
And as per IBM InfoCenter about REFERENCE "The REFERENCE data type holds the location of a field in a message. It cannot hold the location of a constant, a database table, a database column, or another reference."
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 05, 2015 6:05 am Post subject: Re: Why can't we define null REFERENCEs? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
| I imagine that there is a minor performance gain to be had by doing this |
Why would you imagine this? Why would a create and a move be more performant than a create referencing a givien location?
| McueMart wrote: |
| I cant see any documented or logical reason why this shouldn't be technically possible. |
As my associate points out (pun intended) a REFERENCE variable is not a pointer, it's a reference to a location. A null location makes no sense, and that's why if you MOVE to a location that doesn't exist, the REFERENCE still points someplace.
For the record, I've told WMB developers under training to "think of it like a pointer" when introducing the topic; this doesn't make it a pointer and I then have to explain the differences at a later point, especially the importance of the LASTMOVE function.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| McueMart |
| Posted: Mon Jan 05, 2015 7:26 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| Why would you imagine this? Why would a create and a move be more performant than a create referencing a givien location? |
I think you misunderstand my point a tad. What Im saying is that I think that creating a 'null pointer', and then later moving it, would be more performant than creating a REFERENCE which points to an arbitrary tree (lets say Environment) , and later moving it.
Creating a 'null pointer' would basically be a no-op for the runtime - whereas creating a REFERENCE which points to a particular place in the logical tree, *must* involve more processing (I imagine it will have to traverse the tree to find the memory location of that point in the tree).
| Quote: |
| As my associate points out (pun intended) a REFERENCE variable is not a pointer, it's a reference to a location. A null location makes no sense, and that's why if you MOVE to a location that doesn't exist, the REFERENCE still points someplace. |
I do completely understand REFERENCEs. I am just challenging their implementation  You say that null location makes no sense - I'm not sure I agree - that's like saying a null object makes no sense in java. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 05, 2015 7:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
| I think you misunderstand my point a tad. What Im saying is that I think that creating a 'null pointer', and then later moving it, would be more performant than creating a REFERENCE which points to an arbitrary tree (lets say Environment) , and later moving it. |
No, I understood that.
| McueMart wrote: |
| Creating a 'null pointer' would basically be a no-op for the runtime - whereas creating a REFERENCE which points to a particular place in the logical tree, *must* involve more processing (I imagine it will have to traverse the tree to find the memory location of that point in the tree). |
WMB / IIB is very good at traversing the tree.
| McueMart wrote: |
| I do completely understand REFERENCEs. I am just challenging their implementation |
I don't think you're challenging; I think you're dancing on the head of a pin.
| McueMart wrote: |
| You say that null l location makes no sense - I'm not sure I agree - that's like saying a null object makes no sense in java. |
No it's not. A null object in Java makes as much sense as a null value in a database table, i.e. a lot as it conveys something relevant to the application. I don't see a REFERENCE in the same light.
The solution is of course simple. If you think the implementation is flawed and there are performance gains to be made with this function that would justify the effort to develop it, raise an RFE. If enough people agree with you, the feature will be developed.
That's why IBM created RFEs.
Note that it's acceptable (and helpful) to include a link to this thread in the RFE. You should also post the RFE link here to facilitate people voting on it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| McueMart |
| Posted: Mon Jan 05, 2015 7:45 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| I don't think you're challenging; I think you're dancing on the head of a pin. |
Well thanks for the smug insult. Im not quite sure why you thought that was required? Bad day?
As a developer, these kind of things interest me, and I think others may also be interested in discussing them. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 05, 2015 7:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want to absolutely minimize any performance impact, you can just set the reference to point to OutputRoot. That will cause no navigation at all - at the DECLARE statement.
The main use of a REFERENCE is to be able to do tree navigation once rather than every time. So having to do a single MOVE to point the reference somewhere doesn't change that. But being able to point to a known location further down the tree can avoid the MOVE in the first place (although not the actual tree navigation!)
It's not really clear that there would be a lot of value in being able to define a REFERENCE as a NULL value up front. You would still have to do the necessary tree navigation to get it where you want it. And you can only choose to break that navigation into pieces (initial navigation to the value on the DECLARE, and then further navigation at first use). Using a NULL value on DECLARE would, again, only do the navigation in one piece, at first use.
There are probably solid under-the-covers reasons for not being able to set a REFERENCE to NULL - things like the difference between setting an element to NULL versus setting the VALUE to NULL. Except that REFERENCES aren't Tree Element variables, so they don't have a separate VALUE. |
|
| Back to top |
|
|
| McueMart |
| Posted: Mon Jan 05, 2015 8:07 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| If you want to absolutely minimize any performance impact, you can just set the reference to point to OutputRoot. That will cause no navigation at all - at the DECLARE statement. |
Do you mention OutputRoot just because it's the root of the tree? Or is there something special about it? i.e. would 'Environment', 'InputRoot', 'OutputRoot', 'InputLocalEnvironment' etc all be the same performance-wise?
| Quote: |
| It's not really clear that there would be a lot of value in being able to define a REFERENCE as a NULL value up front. You would still have to do the necessary tree navigation to get it where you want it. And you can only choose to break that navigation into pieces (initial navigation to the value on the DECLARE, and then further navigation at first use). Using a NULL value on DECLARE would, again, only do the navigation in one piece, at first use. |
So this brings up interesting questions. If I have 3 references which will have final destinations of:
REFERENCE A => Environment.Variables.MyVar1
REFERENCE B => InputRoot.XMLNSC.A.B.C
REFERENCE C => OutputRoot.DFDL.X.Y.Z
but I want to declare them at the module scope before the destinations exist, would it be most performant to:
DECLARE A REFERENCE TO Environment;
DECLARE B REFERENCE TO InputRoot;
DECLARE C REFERENCE TO OutputRoot. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 05, 2015 8:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I mentioned OutputRoot because it was the Root of a tree, thus zero navigation and always guaranteed to exist.
InputRoot and Environment should be equivalent.
Again, if you want a reference variable to point to OuputRoot.DFDL.X.Y.Z, you're simply going to have to walk the tree down to the Z element. Depending on when and where you do the DECLARE, you can either do that navigation in two places (once to OutputRoot at DECLARE and then once down to Z at MOVE), or in one place (at the DECLARE, once you know that Z exists). |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 05, 2015 9:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
| Quote: |
| I don't think you're challenging; I think you're dancing on the head of a pin. |
Well thanks for the smug insult. Im not quite sure why you thought that was required? Bad day? |
No, day's going quite well thanks. On a bad day I'm much less smug and much more insulting. I'm also worse to people who, unlike yourself, are not making a valid point but just asking ridiculous questions.
What I was attempting to convey was that of all the places in a piece of ESQL that can affect performance, this is a very pedantic place to look with a very limited possible payoff in terms of potential improvement.
I also stand by my suggestion to raise an RFE. If you think it's a valid suggestion then you should do it and not be discouraged by smug strangers on the Internet. You may well discover a groundswell of people who've wanted this feature for ages but don't know about the RFE process voting for it. Or indeed someone at Hursley looking at it and saying, "gosh, yes, null references. We should".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
