If you are working on a script which is taking too long to run and timing out, then this is a simple trick for quickly locating the part which is slow:
os.clock() function returns the approximate time the cpu has been running (with millisecond accuracy), which makes it easy to see how long a piece of code is taking.
Once you have located a slow section there are many ways to deal with the issue, the following pages demonstrate two of these.
Tip: You can adapt this technique for optimizing live code by logging the time instead:
Here is the code if you want to try it out:
function main(Data) os.clock() iguana.logInfo('Time 1: '..os.clock()) -- simulating slow piece of code that takes about 10 seconds -- definitely need to optimize util.sleep(10000) os.clock() iguana.logInfo('Time 2: '..os.clock()) -- this piece of code that takes 1 second -- may want to optimize util.sleep(1000) os.clock() iguana.logInfo('Time 3: '..os.clock()) -- this piece takes 0.1 second it is fast enough util.sleep(100) os.clock() iguana.logInfo('Time 4: '..os.clock()) end
Faster Editor code execution [top]
The ‘iguana’ namespace has two helpful functions for dealing with scripts that can be slow:
iguana.isTest() will return true if the code is running in the context of the editor.
iguana.setTimeout() allows you to specify a different timeout than the default of 5 minutes for when the channel is in production.
So for example say you had a batch interface then within the code you could modify the execution to only process the first 10 messages instead of say 1000 if
iguana.isTest() returns true.
function main(Data) if iguana.isTest() then -- simulate processing 10 messages only -- simulate faster code for testing util.sleep(100) else -- code to process 1000 messages util.sleep(10000) end end
You can use
iguana.setTimeout() to set a shorter timeout than the default 5 minutes for editor code:
function main(Data) if iguana.isTest() then iguana.setTimeout(15) end -- editor code will now get timed out in 15 seconds instead of 5 minutes end
This makes the editor much more responsive and will speed up your interface development process.
Tip: If a live channel is timing out before the code executes you may want to use
iguana.setTimeout() to set a longer timeout than the default 5 minutes, to help debug the code. For example if you give the code more time it could log a useful error message.
Pipeline interface stages [top]
Say you have a web service which pulls back 100 HL7 messages for example.
This web call might take 3 seconds to run which means if you try and write mapping code to process each of those 100 messages within the same Translator instance there will be at least a 3 second delay every time you modify the code.
That will add up to a rather cumbersome development experience.
A way to avoid that is to break the logic into stages so that you have a Translator instance which does the slow operation, in this case giving the example of calling a web service and does at little processing as possible. It should do just enough logic to put the messages into the queue. This could be done in a “From Translator” or filter instance.
Then each of the messages can be mapped much more quickly using sample data in a To Translator or filter Translator instance downstream from the first Translator.
For this example the mapping process can then give almost instantaneous feedback each time the script is executed which will give a much more pleasant and efficient work flow.
Note: You can use pipelining and sample data to improve the development with any From component (not just from a web service).
There are also other benefits from working with sample data, you can source the sample from any source (rather than just from a web service, for example), also you can modify/customize the sample data to suit your needs.