Opened 8 years ago

Closed 7 years ago

#327 closed enhancement (fixed)

Export of results needs to be faster

Reported by: ole Owned by: hudson
Priority: normal Milestone:
Component: Efficiency and optimisation Version:
Severity: normal Keywords:

Description (last modified by ole)

The function sww2dem is being used extensively to produced inundation maps. It is fairly slow since it has never been profiled and optimised. Ideas for optimising it include:

Specify polygon rather than rectangle and assign a value like -9999 to points outside of the polygon. Whether this will speed it up is unclear. Another option would be to profile the function and optimise the bottleneck if there is one.

The function needs some TLC in any case, as it has been evolving over the years without much attention.

Unfortunately, it may be that the slow performance comes from the interpolation code which is known to fairly slow.

Change History (7)

comment:1 Changed 8 years ago by ole

  • Description modified (diff)
  • Type changed from defect to enhancement

comment:2 Changed 8 years ago by ole

  • Owner changed from nariman to nhabili

comment:3 Changed 7 years ago by hudson

  • Owner changed from nhabili to hudson
  • Status changed from new to assigned

comment:4 Changed 7 years ago by hudson

Wrote a benchmark and profiled it. Results are:

Spent 25% of the time building the quadtree in Spent 66% of the time in Spent 50% of the time in

So the interpolation code seems to be the main bottleneck.

I think the idea of creating a file_function with a huge interpolation matrix may be the mathematically correct way of doing it, but it could probably be optimised and simplified a lot to make it run more efficiently.

I don't think there is anything wrong with a quadtree algorithm per se - it could be rewritten in C.

comment:5 Changed 7 years ago by hudson

rev 7700 - marginal 5% speed increase by removing is_inside_triangle wrapper to C function and just calling directly.

comment:6 Changed 7 years ago by hudson

sww2dem benchmark runs about 35% faster with the new code - needs evaluating in real scenarios.

comment:7 Changed 7 years ago by hudson

  • Resolution set to fixed
  • Status changed from assigned to closed

Verified optimisations on Cairns example fitting on XP, Python 2.5:

ANUGA v1.1: 1868.22 seconds ANUGA v1.2: 1527.19 seconds

22% speed increase in ANUGA v1.2.

Note: See TracTickets for help on using tickets.