| Author |
Message
|
| KIT_INC |
 Posted: Tue Dec 22, 2009 7:04 am Post subject: The cheapest node |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I am using WMB 61 on Unix. I just need to set an Environment value to a shared variable. The esql is just (no other processing needed)
DECLARE MYSHARE_VAR SHARED CHAR;
:
SET MYSHARE_VAR= Environment.Variable.DATA.Mydata;
I know I can do it in a compute node. Is compute node more expensive than a filter node (overheads like memory usage) ? Is there any implication of doing it in a filter node which I think may be cheaper? Any suggestion on this or on using other nodes will be greatly appreciated. |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Tue Dec 22, 2009 9:27 pm Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
how you are stating it it impacts the performance.
Do you have any figures or facts in your hand.
if that is the case IBM should not project out most of the nodes.
[Database Nodes /Compute node/ JCN / Filter goes on] 
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Tue Dec 22, 2009 11:35 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi KIT_INC,
I understand your concern on performance, but it does not really come into picture unless you are doing complex flows and every microsecond is priceless.
On the contrary, you should be using the nodes which are meant for the job..especially since someone else after you could be maintaining the code...and I would not want to maintain code where a filter node is being used when you did not need to make a decision (just an example).
Regards. |
|
| Back to top |
|
|
| imakash |
| Posted: Wed Dec 23, 2009 4:54 am Post subject: |
|
|
Newbie
Joined: 22 Dec 2009
Posts: 7
|
| well if you are so concerned about performance you can do that using database node. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Wed Dec 23, 2009 11:34 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| I am coding a subflow for everybody else to use. The share variable is just to tell whoever calls the subflow that work has already been done or not. As I do not know what flow will be calling and how critical performance may be for that flow, I just want to use as little as I can. That's the reason for the question. |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Dec 23, 2009 1:45 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
In terms of absolute minimal overhead, use the Database node to do this...
_________________
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 |
|
|
| Michael Dag |
| Posted: Thu Dec 24, 2009 12:32 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| mgk wrote: |
| In terms of absolute minimal overhead, use the Database node to do this... |
interesting comment I would not have expected the database node to pop-up out of this one, is there a table somewhere that sort of describes the cost of each node in relative terms?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Thu Dec 24, 2009 2:45 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
| Michael Dag wrote: |
| mgk wrote: |
| In terms of absolute minimal overhead, use the Database node to do this... |
interesting comment I would not have expected the database node to pop-up out of this one, is there a table somewhere that sort of describes the cost of each node in relative terms? |
database node wont create the message tree that could be the reason "mgk" suggested that.
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Dec 24, 2009 2:51 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| database node wont create the message tree |
Correct, there is no new message tree created in a DB (or Filter node), whereas there is in a Compute node.
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 |
|
|
| rekarm01 |
| Posted: Thu Dec 24, 2009 4:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
As long as the ESQL is equivalent for Compute, Filter, and Database nodes, the performance difference is probably negligible.
The Compute node creates three empty Output trees; this is not terribly expensive, all by itself. It's the additional ESQL to perform a tree copy that can make it expensive. This could be mitigated by:- either setting 'Compute Mode' to refer to a smaller tree, and copying that; (ExceptionList is usually a good choice)
- or adding a PROPAGATE statement with MessageSources clause to propagate the three Input trees, (as there doesn't seem to be a 'Compute Mode'="None" option), and don't copy any trees
However, the Database node is still a marginally better choice, probably more for aesthetic reasons, than for performance.
Between the Database and Filter nodes, choose whichever one has the more appropriate output terminals.
For more significant performance gains, look elsewhere. |
|
| Back to top |
|
|
| Herbert |
| Posted: Tue Dec 29, 2009 4:37 am Post subject: Re: The cheapest node |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
| KIT_INC wrote: |
I am using WMB 61 on Unix. I just need to set an Environment value to a shared variable. The esql is just (no other processing needed)
DECLARE MYSHARE_VAR SHARED CHAR;
:
SET MYSHARE_VAR= Environment.Variable.DATA.Mydata;
I know I can do it in a compute node. Is compute node more expensive than a filter node (overheads like memory usage) ? Is there any implication of doing it in a filter node which I think may be cheaper? Any suggestion on this or on using other nodes will be greatly appreciated. |
You can do this in a Compute node that is connected to the First terminal of a FlowOrder node (and connect whatever is your next node to the Second terminal of this FlowOrder node). Then there is no need to build a Output Tree in your ComputeNode. (You can even do a RETURN FALSE in the compute node to indicate there is no Out terminal processing needed but because there is nothing connected to this Out terminal I don't think this is really needed). |
|
| Back to top |
|
|
|
|
