Hi,
When running a model, which I made with FME 2016.0, in FME 2016.1, I noticed that the Clipper was doing a significantly slower job. No changes on the model were made and when I run it again in FME 2016.0, everything is well again.
Anyone had similar issues with the Clipper in FME 2016.1? Is this a common problem?
+25
I've built a quick workspace to test this:
Generate a 1000 x 1000 grid of polygons (1 million features in total), clip them with a smaller clipper polygon.
FME 2016.0 build 16174 took 1:37 minutes
FME 2016.1 build 16492 took 1:45 minutes
Both are the 64-bit versions, on the same machine, so yes, it does seem there's something fishy going on there.
The Clipper is not upgradeable between 2016.0 and 2016.1 so that can't be the solution. Removing the Clipper in 2016.1 and placing a new one doesn't make much of an appreciable difference.
I'm sure somebody from Safe Support will pick up on this thread, I've attached my workspace.
The difference in runtime is remarkably slower in my case. In 2016.0 it runs for about 4 minutes. In 2016.1, I had to stop the run after 30 minutes because it was not even halfway trough clipping all my features. Anyone else??
I've also noticed that clipping is really slow (2016.1) i've only been using FME since 2016 so i haven't got much to base this on. due to inexperience i just thought FME wasn't very efficient at clipping (a model i am in the process of making takes about 35 minutes to do a clip operation that would finish very quickly in ArcMap) I was origianlly going to create a secondary ArcMap modelbuilder workflow to clip my FME outputs - maybe this won't be needed after all if this is just some kind of bug.
+9
Hi @bakkermans,
We would like to get to the bottom of this issue. Would you be able to send in your workspace and sample data so that we can reproduce this? You can send this to support@safe.com. Please do add my name to either the body or subject of the email and I will make sure to get this to our development team.
Kind regards,
Brian Pont
Safe Support Team
The difference in runtime is remarkably slower in my case. In 2016.0 it runs for about 4 minutes. In 2016.1, I had to stop the run after 30 minutes because it was not even halfway trough clipping all my features. Anyone else??
That is not good at all. I will file this with the developers and include the workspace from @redgeographics
If you too (or anyone else) can provide us a workspace/data, then please do. You can either post it here or file a support case with us (safe.com/support)
I know we'll take it very seriously. Being slow compared to anyone else is bad. Being slow compared to our former selves is even worse.
I've built a quick workspace to test this:
Generate a 1000 x 1000 grid of polygons (1 million features in total), clip them with a smaller clipper polygon.
FME 2016.0 build 16174 took 1:37 minutes
FME 2016.1 build 16492 took 1:45 minutes
Both are the 64-bit versions, on the same machine, so yes, it does seem there's something fishy going on there.
The Clipper is not upgradeable between 2016.0 and 2016.1 so that can't be the solution. Removing the Clipper in 2016.1 and placing a new one doesn't make much of an appreciable difference.
I'm sure somebody from Safe Support will pick up on this thread, I've attached my workspace.
Hi Hans - can you attach the log files from the two runs? We've tried it on our machines (with various builds from 2016.0 to 2017) and get a consistent 1:30 minutes.That might be the developer's machine that makes the difference, so I'm wondering if we can pinpoint where the difference occurs in the log.
I've also noticed that clipping is really slow (2016.1) i've only been using FME since 2016 so i haven't got much to base this on. due to inexperience i just thought FME wasn't very efficient at clipping (a model i am in the process of making takes about 35 minutes to do a clip operation that would finish very quickly in ArcMap) I was origianlly going to create a secondary ArcMap modelbuilder workflow to clip my FME outputs - maybe this won't be needed after all if this is just some kind of bug.
I would definitely check the option for "Clippers First". Do a search in the knowledgebase and on our blog for more info. That one setting *can* make a huge difference.
I've built a quick workspace to test this:
Generate a 1000 x 1000 grid of polygons (1 million features in total), clip them with a smaller clipper polygon.
FME 2016.0 build 16174 took 1:37 minutes
FME 2016.1 build 16492 took 1:45 minutes
Both are the 64-bit versions, on the same machine, so yes, it does seem there's something fishy going on there.
The Clipper is not upgradeable between 2016.0 and 2016.1 so that can't be the solution. Removing the Clipper in 2016.1 and placing a new one doesn't make much of an appreciable difference.
I'm sure somebody from Safe Support will pick up on this thread, I've attached my workspace.
fwiw, I tested this and there was a 5 second slowdown.
However, the slowdown was right at the start when the source data was
created, not in the clipping
2016.0
0.3| 0.0|INFORM|Emptying factory pipeline
0.3| 0.0|STATS |Creator_XML_Creator(CreationFactory): Created 1 features
0.3| 0.0|STATS |Creator_Cloner(TeeFactory): Cloned 1 input feature(s) into 1 output feature(s)
8.8| 8.5|STATS |Clipper_ClipperCloner(TeeFactory): Cloned 1 input feature(s) into 2 output feature(s) 2016.1
0.3| 0.0|INFORM|Emptying factory pipeline
13.4| 13.1|STATS |2DGridCreator_CREATED Brancher -1 5(BranchingFactory): Branched 1000000 features
13.4| 0.0|INFORM|Adding Clipper 1
13.4| 0.0|STATS |Creator_XML_Creator(CreationFactory): Created 1 features
13.4| 0.0|STATS |Creator_Cloner(TeeFactory): Cloned 1 input feature(s) into 1 output feature(s)
13.4| 0.0|STATS |Creator_CREATED Brancher -1 4(BranchingFactory): Branched 1 input feature -- 1 feature routed to the target factory
13.4| 0.0|STATS |_CREATOR_BRANCH_TARGET(TeeFactory): Cloned 1000001 input feature(s) into 1000001 output feature(s)
13.4| 0.0|STATS |Clipper_ClipperCloner(TeeFactory): Cloned 1 input feature(s) into 2 output feature(s)Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.