Opened 15 years ago

Closed 13 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 15 years ago by ole

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

comment:2 Changed 15 years ago by ole

  • Owner changed from nariman to nhabili

comment:3 Changed 14 years ago by hudson

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

comment:4 Changed 14 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 14 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 14 years ago by hudson

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

comment:7 Changed 13 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.