2013-10-13

Getting Started with Tcl in FME: Other Transformers

=====
2015-02-22 Note: The @Evaluate function of FME 2015 will not return non-numeric value any longer. If the Tcl expression which is embedded to the argument for the function returns non-numeric, the @Evaluate functions will return <null>. Therefore, the following examples are unavailable in FME 2015 unfortunately.
=====

Several transformers other than the TclCaller and the AttributeCreator also accept Tcl commands in the parameter setting. Here I'll give some examples.
FME 2013 SP4 Build 13545 Win32

StringConcatenator with this setting creates a concatenated string consisting of initial characters of "first" and "last". When "first" = "Takashi" and "last" = "Iijima", for example, the result will be "TI".
@Evaluate([string index {@Value(first)} 0])@Evaluate([string index {@Value(last)} 0])
* Shown in the Advanced String Editor

FeatureMerger with this setting merges features on the first character of requester's "attr" and the value of supplier's "initial"; assume "initial" contains one character.
Requestor: @Evaluate([string index {@Value(attr)} 0])
Supplier: initial (an attribute name of the supplier)

Not only these transformers but also some other transformers might accept Tcl commands. And some Tcl commands can be replaced with FME String Functions.

When does the Tcl interpreter "compile" those commands?
Here is a thought-provoking description.

"A drawback of the ExpressionEvaluator is that it uses TCL and therefore the TCL interpreter. Every time a feature passes through it, the expression has to be "compiled" before the calculation can be made. So 1 million features = 1 million compilations!"
-- FMEpedia > ExpressionEvaluator > ExpressionEvaluator Performance

Guessing from this, Tcl commands embedded in a transformer parameter probably will be "compiled" every time a feature passed in (am I wrong?). We should be aware of this point especially when we have to process a very large number of features. In certain cases, Python script could be more efficient than Tcl commands.

Of course Python is not always the best solution; Python is just one of the choices. The best solution should be determined according to the actual conditions and several viewpoints - not only efficiency but also maintainability, understandability etc.. I think that the important thing is to have many choices as long as possible, to create more effective workspaces.