Opened 22 years ago
Closed 22 years ago
#162 closed defect (fixed)
MapServer 3.6 slower than 3.5?
Reported by: | dmorissette | Owned by: | sdlime |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | MapServer CGI | Version: | 3.6 |
Severity: | normal | Keywords: | |
Cc: |
Description
Hi Steve, We've had a user report to us that MapServer 3.6 (release) was slower than 3.5 (release). We investigated this, and he was indeed right. MapServer 3.6 was approximately 50% slower than 3.5 on the same mapfile. We used gprof to find out that most of the time difference comes from msImageFilledPolygon(). Our test was a set of 10 shapefiles (approx 10MB), and running it 15 times with gprof gave the following results: Total time msImageFilledPolygon() MapServer 3.5 34.2 sec 23.6 sec MapServer 3.6 47.3 sec 36.5 sec The configuration options between the two versions were identical, same copy of GD linked statically, etc. Pointing to the same mapfile on the same HD, doing a plain polygon fill in both cases. Do you have any idea what may have changed to justify that difference? We can make the full set of gprof reports available to you if that can help. Daniel
Change History (5)
comment:3 by , 22 years ago
For the record, after Julien's changes to msImageFilledPolygon(), we went from MapServer 3.6 being 50% slower rendering polygon fills to it being almost 20% faster than 3.5!!! This optimization has been applied to 3.6 and will be applied to 3.7 as well... further optimizations may be done down the road in the 3.7 branch only. Here are the new times for 15 iterations with the optimized code: Total time msImageFilledPolygon() MapServer 3.5 34.2 sec 23.6 sec MapServer 3.6 30 sec approx 20 sec? As Julien mentioned, there were two source code lines in critical areas of msImageFilledPolygon() that were doing copies of pointObj structures (i.e. point1 = point2;)... and that's where the 10 seconds of difference were spent. In 3.5, pointObj was: typedef struct {double x, double y} pointObj; In 3.6, we added measured shapefiles, and it became: typedef struct {double x, double y, double m} pointObj; It turns out that this little increase in the size of the pointObj struct is what was costing us all that processing time. After the code was changed to use pointers instead of copies of pointObj then we got the gain of performance described above (i.e. yes, 3.6 is really faster than 3.5 now!)
comment:5 by , 22 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The change in 3.7 are commited. I have finished the test and it does not appear to have any problem. So, I'm closing the bug.
Note:
See TracTickets
for help on using tickets.