Assessing Performance

Assessing the performance of a workspace such as this:

...requires a bit of time and attention, but knowing how a workspace performs helps to make informed decisions on how to best design (or redesign) it.

When testing for performance ensure that there is only one instance of FME running, and all other non-essential programs are closed. You'll also require something to record your times on, like a piece of paper.

Assessing Reader Performance

To be able to improve the efficiency of a reader requires an estimate of how well it is working in the first instance, yet this can be hard to separate out in a workspace that is also transforming data.

The key message that signifies reading is complete is “Emptying Factory Pipeline”. Here, for example, reading of the data finished after 26.4 seconds of processing (of course the actual elapsed time might be longer if FME was waiting for a database or the file system to respond):

2018-06-29 11:48:54|  26.4|  0.0|INFORM|Emptying factory pipeline

However, sometimes that message can be misleading. FME processes the data at the same time it is reading it, so that it won't read an entire data set before processing. To avoid this confusion, disable all the transformers and simply run the reading part of the workspace:

With the transformers disabled, the message now appears much sooner:

2018-06-29 11:49:35|   1.2|  0.0|INFORM|Emptying factory pipeline

So we can tell that reading the data is only taking 1.2 seconds.

Assessing Writer Performance

As with readers, you can't improve the performance of a writer unless you can first assess how well it is already performing. However, assessing the speed of writing has the same complexity as reading: FME starts writing data as soon as it becomes available and doesn’t necessarily wait until processing is done.

So, how can we assess writer performance? Assessing a writer is clearly different to a reader. If you isolate the writers by disabling everything else, there won't be any data to write!

The easiest way is to disable the writer itself!

If the original result was this:

2018-06-29 11:54:14|  26.5|  0.0|INFORM|Translation was SUCCESSFUL with 19 warning(s) (148 feature(s) output)
2018-06-29 11:54:14|  26.5|  0.0|INFORM|FME Session Duration: 26.7 seconds. (CPU: 22.5s user, 4.0s system)

...and with the writer disabled it is now this:

2018-06-29 11:56:48|  26.6|  0.0|INFORM|Translation was SUCCESSFUL with 19 warning(s) (0 feature(s) output)
2018-06-29 11:56:48|  26.6|  0.0|INFORM|FME Session Duration: 26.6 seconds. (CPU: 22.1s user, 4.4s system)

...then we can easily calculate that the writing process is taking merely 0.1 seconds.

Assessing Transformer Performance

Assessing the time taken in transformation requires a two-step process.

First, disable writers and run the translation, taking note of the elapsed time:

Then disable the transformers too and rerun the workspace, to calculate the time taken to read the data only. The difference in elapsed time between reading the data and reading/transforming the data is the elapsed transformation type.

It's important not to add an Inspector or Logger transformer to the end to see what is happening to the output. This will slow the translation down and give you a false measure. You must also be sure to disable the actual writer and not just the feature types or connections to them.

The only writer that is useful in this scenario is the Null format writer. This causes a writer to be present, but it does nothing except to count features and then discard them. The benefit is improved logging of feature counts, but without any data having to be written.

WARNING

Naturally, where a FeatureReader or FeatureWriter transformer is used, assessing reading and writing requires a different procedure: It would be necessary to run the workspace twice; once with everything disabled after that point, and once with everything disabled up to (and including) that point. Then subtract the two run-times to get the correct result.