Homepage › Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › hcitbllookup vs switch statement
- This topic has 18 replies, 11 voices, and was last updated 9 years ago by Russ Ross.
-
CreatorTopic
-
June 20, 2014 at 2:30 pm #54276Greg TatarynParticipant
Looking at trying to increase efficiency on our engine and I was curious which is more efficient or if the difference is negligible, using an hcitbllookup or using a switch statement to take in data, check it and translate it to something else? In our case we are taking in a string for the full facility name and changing it to a single letter.
-
CreatorTopic
-
AuthorReplies
-
-
June 20, 2014 at 8:41 pm #80817Jim KosloskeyParticipant
You should be able to test that yourself.
Write 2 procs one with switch and one with Table Lookup.
Include some measurement code (look to the clock command) and echo out the metric.
Run the same test against both and see the difference.
I recall the Table handling is really quite efficient both in storage and execution (inside the engine particularly).
If this is a large table subject to frequent changes then of the 2 solutions the Table is probably easier to maintain by anyone.
If the data is available externally then an even better solution is to have someone else maintain the data then reference that. There are a number of ways to do that including exporting from the source to a delimited file and building a lookup table from that. Other have loaded to SQLite, and some have even referenced such data directly from the source if it is a DB. Yet others have other solutions.
Personally I don’t write any more Tcl than I need to so in this situation I would lean towards a lookup table based solution (inside an Xlate if possible). But that is me.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
June 21, 2014 at 1:15 am #80818Charlie BursellParticipant
I get on this soapbox from time to time 😀
At least 60 – 75 percent of the life cycle cost of any software project is in the maintenance!
Think about the purpose of an integration engine. Surely any point to point interface written in any language for a specific purpose would be much more ergonomic than any off the shelf integration engine.
However, consider which is more maintainable if a change occurs. Would it be the GUI based system where you simple make a change or a piece of software? That software must be understood if not written by you (sometimes even if written by you), edited, tested, regression tested, and even sometimes go through source control and QA.
Sometimes, for weird stuff, we have no choice. That should not ne the norm.
Nuff said. Off the soapbox now.
-
June 23, 2014 at 11:38 am #80819Greg TatarynParticipant
Thank you both for the responses. I agree for maintenance a table is MUCH easier but there had been some debate over efficiency. I will definitely look into making copies of my scripts and running some tests on them. I was just not 100% sure on how to best test it all out.
-
June 24, 2014 at 1:30 am #80820Richard HartParticipant
Hi Greg.
We have previously compared performance of TCL code with and without table lookups and found little extra cost.
We have now moved a lot of tables to CSV files. This enables an application support group to ‘own’ the table (spreadsheet, XLS format) and we just ‘save as CSV’ and migrate.
If you do use this, be very careful as the spreadsheet load of a CSV file will remove leading zeros from the columns!
-
June 24, 2014 at 11:07 am #80821Jim KosloskeyParticipant
Greg,
A couple of considerations for your testing:
Do your testing inside the engine (after all this is probably where you will actually be doing the work).
For the Table measurement, start your test after the first lookup as that triggers the loading of the table in memory. After the first message all lookups will be done from memory.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
June 25, 2014 at 9:00 pm #80822Jeff DinsmoreParticipant
I’ve found Cloverleaf’s table lookup to be very quick, so I wouldn’t code table-type info directly into a TCL procedure to make it faster.
In addition to the clock command that Jim mentioned, you can get better resolution with the time command.
When I’m doing time comparisons, I’ll usually set it up to run a large number of executions and then average the values. Comparisons of timing with one-iteration values can be skewed. I also think that table lookups from the Cloverleaf TCL command prompt will give you valid results. I don’t think you need to run them in the engine itself for a comparison like this.
Here’s timing on a table lookup:
Code:hcitcl>set workType cu
cu
hcitcl>time {set docType [tbllookup escription_doc_types.tbl $workType]} 1000
1.804 microseconds per iterationA proc that does the same thing with a switch is not much faster:
Code:hcitcl>set workType cu
cu
hcitcl>time {switchCode $workType} 1000
1.191 microseconds per iterationCharlie’s point about maintainability is a good one. If the info you’re looking up changes frequently, use a table – or some other method that’s external to the code. If it doesn’t change, or does so very infrequently, it’s OK to keep it inside your interface code.
If your data contains two columns, a table works well enough. If it contains more than two columns, or if you need bi-directionality without a unique one-to-one relationship in both directions, you’re out of luck and need to use another tool.
I, personally, like SQLite because of it’s functionality, it’s performance – and its price – so, I most often will use it instead of a Cloverleaf table.
Jeff Dinsmore
Chesapeake Regional Healthcare -
June 27, 2014 at 10:42 am #80823Robert KersemakersParticipant
Yes: maintainability is most import, in my opinion.
You can use tables if you need more than 2 columns/fields; see screenprint 1.
Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
-
June 30, 2014 at 11:51 am #80824Gretchen MacdowallParticipant
Another way to get the multiple values in column B is to use a delimiter that won’t be in the data, like ^. Of course then you have to split the result, but that’s how I did one table.
-
September 10, 2015 at 5:42 pm #80825Kapil VagyaniParticipant
Hi,
In Xlate can I use ITERATE over list variable (i.e. @list). this variable holds value returned by tcl proc.
Pls refer attachment for more details.
Any help will be appreciated.
Thanks,
Kapil
-
September 10, 2015 at 6:10 pm #80826James CobaneParticipant
Kapil,
I’m not sure I fully understand your question, but you can essentially manipulate the value of any iteration variable by referencing it with the $ nomenclature; i.e. COPY =1 –> $%l1
-
September 10, 2015 at 6:18 pm #80827Kapil VagyaniParticipant
Thanks Jim for reply!
Let me elaborate the problem statement….
I have declared temp variable in xlate called ‘@mylist’. this variable holds the data in list format e.g. {1 2 3 4 5 6….}.
I tried using ITERATE command in xlate to iterate through the above list
i.e. In ITERATE Command I filled in below attribute values;
Type :lits
Basis : @mylist
Variable : %l1
Now when I tried echo values of ‘%l1’ variable I am not getting expected output. it prints value as “@list”.
so wanted to know is it supported in cloverleaf do iterate over variable?
Pls feel free to reply in case you have further question about problem statement.
Regards
-
September 10, 2015 at 6:35 pm #80828Jim KosloskeyParticipant
Kapil,
Cloverleaf 6.0 doc iindicaattes you can do what you want – but I hav not gotten it to work. It appears you are on even a leter release and it is not working there either.
I think I undeerstand what you want and I wwill try to share how I do that.
In your ITERATE set your basis to ‘0 1’.
We have a proc which pops off the top element of a list and returns that element plus the remaining list.
So initialize a temp variable (let’s use @elem) before the ITERATE.
Execute Tcl (inline or a proc) to pop off the top element of @list and return @elem and @list.
Inside the ITERATE check @elem eq @null (if it is the list has been fully processed) and COPY =2 to $%l1 (this effectively ends the ITERATE since the counter is now greater than the number of elements in the basis)
ELSE (means there is more in the list) COPY =0 to $%l1 (this resets the ITERATE to the start) and do whatevvr you want with @elem (like COPYing to an outbound field, etc.).
If you would like thee proc we use to pop off the list element email me.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
September 10, 2015 at 7:05 pm #80829Kapil VagyaniParticipant
Sounds good idea! 🙂
Yes I am using CLR v6.1
I will try suggested trick and let you know how it goes.
Once again many thanks!
Kapil
-
September 10, 2015 at 10:54 pm #80830Jim KosloskeyParticipant
The List ITERATE ‘trick’ is not mine. Another Clovertech member shared this some time ago.
Sadly I do not remember who so I cannot give proper credit.
The proc was written for us by Don Ramey a former employee and all around goood guy.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
September 11, 2015 at 7:44 am #80831Robert KersemakersParticipant
Oh oh! A chance to reignite my five minutes of fame!
It was 8 years ago when… http://clovertech.infor.com/viewtopic.php?t=2213
🙂
Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
-
September 11, 2015 at 7:51 am #80832Marc PleijersParticipant
Hi all,
Regarding the post on using a temp variable (e.g. @var) as a basis for an iteration, I can inform you about the following:
According to the documentation you should be able to use a temp variable as a basis for an iteration.
However we tried this and it did not work.
We registered a call for this in InforXtreme Case number: 8849524
Infor replied that this is a bug and it is planned to be solved in Cloverleaf 6.2
AR number for 6.2: AR12925
Kind Regards,
Marc Pleijers
Marc Pleijers
Senior Integration Consultant
Enovation BV
The Netherlands -
September 11, 2015 at 12:19 pm #80833Jim KosloskeyParticipant
Robert – Sorry I could not remember you posted this – I don’t use this often but it realy comes in handy.
Marc,
Hopefully when they fix that you will get the value of the counter when referencing it and not the positional value of the element of the list. If fixed correctly, this will be a welcome functionality.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
September 13, 2015 at 5:20 am #80834Russ RossParticipant
with regards to
Code:Regarding the post on using a temp variable (e.g. @var) as a basis for an iteration, I can inform you about the following:
According to the documentation you should be able to use a temp variable as a basis for an iteration.
However we tried this and it did not work.That sounds familiar to me and I sort of recall I had to match the construct of the variables typically used for iteration.
So for a list iteration I might use a temp variable like $%l9, for a group iteration I might use a temp variable like $%g9, for a segment iteration perhaps a temp variable like $%s9.
Unfortunately, this restriction does take the use of a meaningful temp variable off the table, which is more desirable.
Russ Ross
RussRoss318@gmail.com
-
-
AuthorReplies
- The forum ‘Cloverleaf’ is closed to new topics and replies.