Best way to start developing using parallel jobs
Moderators: chulett, rschirm, roy
Best way to start developing using parallel jobs
I have a good experience of doing development using Server jobs, but
now client wants to use DS Parallel Jobs.
Could you tell me please what is the best approach to make a smooth
transition to the DS Parallel Edition from DS Server Edition? and in
your opinion how difficult/time consuming is it?
now client wants to use DS Parallel Jobs.
Could you tell me please what is the best approach to make a smooth
transition to the DS Parallel Edition from DS Server Edition? and in
your opinion how difficult/time consuming is it?
Edited by Mike3000
No need to avoid the transformer stage as its performance has been greatly increased in 7.x versions. No doubt, modify stage still leads the two, but transformer is faster than filter stage and a few other stages. IBM released this information sometime back.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
Yes ,You may worng sir...Bcz Xrm is generate the c++ code and this stage consumed the large memory compary to other stages.
Other stages generate the hash file entrys.That is the resone to avoid the Xrm stage. Xrm stage want so many section leaders and players.
But other stages not like that.....if i am worng correct me...
Other stages generate the hash file entrys.That is the resone to avoid the Xrm stage. Xrm stage want so many section leaders and players.
But other stages not like that.....if i am worng correct me...
True. But my comment was w.r.t performance.
Memory demands follow simple economics. Demand and supply. I have never had memory leaks with a transformer stage. I have had memory violations while using custom px routine but that was my own faulty memory management in the C code. Other than that, the transformer jobs run like a breeze.
Memory demands follow simple economics. Demand and supply. I have never had memory leaks with a transformer stage. I have had memory violations while using custom px routine but that was my own faulty memory management in the C code. Other than that, the transformer jobs run like a breeze.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Hi DSGuruDSguru2B wrote:No need to avoid the transformer stage as its performance has been greatly increased in 7.x versions. No doubt, modify stage still leads the two, but transformer is faster than filter stage and a few other stages. IBM released this information sometime back.
Can you share the link where IBM document is available that speaks about comparison of Filter and Transformer (transformer is faster than filter stage and a few other stages. IBM released this information sometime back)
I tried to search IBM and Ascential Developer Net (IBM Forum) , i did not manage to get the same.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The information that IBM released "some time back" was for version 7.0 and earlier and has been overtaken by events. Now they're advising (in their training classes) that Transformer should be perferred to Filter, on the grounds that it's compiled and Filter is "interpreted". I believe the justification is spurious, because the filter operator is an instance of an object for which the class is written in C++, so there ought to be little to choose between them. But I have no benchmarks to support that belief.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.