Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » GEF4 Geometry performance
GEF4 Geometry performance [message #1729077] Mon, 11 April 2016 01:16 Go to next message
Colin Sharples is currently offline Colin SharplesFriend
Messages: 90
Registered: July 2009
Location: Wellington, New Zealand
Member

Has there been any performance testing done on the GEF4 Geometry component?

I'm finding that for very large scenes with complex shapes, operations like contains() and intersects() don't perform all that well. There's a lot of temporary objects that get created, and there are many properties that could be cached but are instead calculated every time (see Polygon.getOutlineSegments() for example).

In my case, I have many shapes that do not change after they are initially created, so it would almost certainly improve performance if caching were used - the overhead of always having the additional objects in memory would be significantly less than creating new objects whenever required.

I can think of two ways to handle caching:
1. Set a caching mode on the existing classes. This would either passed as a constructor argument, or set at a package level e.g. as a static property on AbstractGeometry
2. Create a subpackage of o.e.g.g.planar, containing cached versions of the concrete geometry classes.

From an API point of view, which would be preferable?


Colin Sharples
CTG Games Ltd
Wellington, New Zealand
Re: GEF4 Geometry performance [message #1729156 is a reply to message #1729077] Mon, 11 April 2016 14:59 Go to previous messageGo to next message
Alexander Nyssen is currently offline Alexander NyssenFriend
Messages: 235
Registered: July 2009
Location: Lünen
Senior Member
We have done some basic performance tests, but an optimization w.r.t. object creation has not been performed yet.

We could think of adding certain caching mechanisms for expensive computations, but I would not like to expose this via the API (it should stay an implementation detail). I could think of two improvements:

1) cache results of expensive computations (and clear the cache whenever the related input data changes), but internally
2) see if we can minimize object creations
Re: GEF4 Geometry performance [message #1729177 is a reply to message #1729156] Mon, 11 April 2016 19:20 Go to previous messageGo to next message
Colin Sharples is currently offline Colin SharplesFriend
Messages: 90
Registered: July 2009
Location: Wellington, New Zealand
Member

Thanks. I've had a look through and realized that it's a bit more complicated than I first thought. Accessors like BezierCurve.getP1() and getP2() currently return new objects, so it's likely that clients would be relying on that. You can't just change those methods to used cached properties, so you would have to look through the internal usages of these methods and replaced with cached version. That's quite a bit of work.

However, I think this is a fairly important improvement. The performance is perfectly good for typical editor scenarios, but starts to be an issue with very large scene graphs or rapid updates. My use case is a game - I have a background of many very large shapes representing terrain, and then smaller shapes which move through the terrain. One thing I need to do is test visibility, i.e from one of the moving shapes test all of the background shapes within a certain radius to see if they block line of sight. That involves a lot of calls to intersects(), contains() and overlaps(). Currently this is not meeting my performance requirements, and I've tried all the optimizations I can on the client side. I have made extensive use of Java 8 streams - using parallel streams to filter shapes, for example, results in quite significant gains. Would you consider (post Neon) moving to Java 8 as the base execution environment? Many of the testing methods would benefit from the parallel stream short-circuiting operations.

In the meantime, I am happy to contribute however I can. I'd be able to create some test scenarios, given that I have a lot of real world data. I can also see if I can implement your suggested caching approach on one or two of the shape classes.


Colin Sharples
CTG Games Ltd
Wellington, New Zealand
Re: GEF4 Geometry performance [message #1729289 is a reply to message #1729177] Tue, 12 April 2016 15:19 Go to previous message
Alexander Nyssen is currently offline Alexander NyssenFriend
Messages: 235
Registered: July 2009
Location: Lünen
Senior Member
Quote:
Thanks. I've had a look through and realized that it's a bit more complicated than I first thought. Accessors like BezierCurve.getP1() and getP2() currently return new objects, so it's likely that clients would be relying on that. You can't just change those methods to used cached properties, so you would have to look through the internal usages of these methods and replaced with cached version. That's quite a bit of work.


Not necessarily. That depends on whether we want to primarily optimize performance or memory (or both). In the first case, we could also think of caching computation results (of costly computations), while still returning newly instantiated objects. For the latter we would indeed have to find shortcuts for internal usage, where we might reduce object instantiation. Probably, it will be worth taking a look at both.

Quote:
However, I think this is a fairly important improvement. The performance is perfectly good for typical editor scenarios, but starts to be an issue with very large scene graphs or rapid updates. My use case is a game - I have a background of many very large shapes representing terrain, and then smaller shapes which move through the terrain. One thing I need to do is test visibility, i.e from one of the moving shapes test all of the background shapes within a certain radius to see if they block line of sight. That involves a lot of calls to intersects(), contains() and overlaps(). Currently this is not meeting my performance requirements, and I've tried all the optimizations I can on the client side. I have made extensive use of Java 8 streams - using parallel streams to filter shapes, for example, results in quite significant gains. Would you consider (post Neon) moving to Java 8 as the base execution environment? Many of the testing methods would benefit from the parallel stream short-circuiting operations


Yes, we plan to change the BREE of all our bundles from 1.7 to 1.8 after the 1.0.0 (Neon) release.

Quote:
In the meantime, I am happy to contribute however I can. I'd be able to create some test scenarios, given that I have a lot of real world data. I can also see if I can implement your suggested caching approach on one or two of the shape classes.


I would highly appreciate that.
Previous Topic:FXHoverTool should only look at nodes contained within the IViewer
Next Topic:Constrain size of InfiniteCanvas
Goto Forum:
  


Current Time: Wed Sep 26 03:14:58 GMT 2018

Powered by FUDForum. Page generated in 0.01682 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top