[mapguide-users] perfomance test

[Traian Stanev]

Yes 38 might be too many for linear... May be SDF would become faster if
we changed it to use std::map in that case. :-)

  _____  

From: Haris Kurtagic [mailto:haris at sl-king.com] 
Sent: Monday, November 06, 2006 5:33 PM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] perfomance test


Yes i am using std::map now (i am still working on this), i will look at
sdf ( he is the fastest man arround, one to look at).
For geometries I already have seperate list of keeping index of it.
The example I used in test was with 38 attributes.
 
Thanks for suggestions,
Haris

  _____  

From: Traian Stanev [mailto:traian.stanev at autodesk.com] 
Sent: Monday, November 06, 2006 11:28 PM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] perfomance test


Did you try to use a map instead of a hash_map? I have found
(empirically) that in most cases std::map will perform better than
std::hash_map.
Also for SDF I used a linear search approach -- look in
PropertyIndex.cpp, line 121. The provider maintains a list of the class
properties and their data type for quick access. The advantage of this
is that if you list the geometry property first, you will be paying
essentially no overhead to get the index of the geometry property.
However, linear hurts more than std::map if you have a large number of
attributes or you are getting too many of them.
 
Traian
 
 

  _____  

From: Haris Kurtagic [mailto:haris at sl-king.com] 
Sent: Monday, November 06, 2006 5:08 PM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] perfomance test


Hi Jason,
 
I checked again about this slow attributes fetching, and it was poor
perfomance in provider. 
I have corrected it so this time instead of 18 sec is 6 sec.
 
btw:
Problem was that FDO fetch properties using property name and than you
need to use strings to find right index in query result set.
I forgot about that one, I mantioned that already on fdo dev list but
forgot to optimize in provider. (Now using hash maps for quicker finding
match)
To allow index based access to properties would be my first fdo rfc when
rfc's starts for fdo :).
 
Haris

  _____  

From: Jason Birch [mailto:Jason.Birch at nanaimo.ca] 
Sent: Sunday, October 29, 2006 11:18 PM
To: users at mapguide.osgeo.org
Subject: RE: [mapguide-users] perfomance test


Haris,
 
Those are some really interesting results.  I'd like to see what happens
with spatial index optimisation, but I am mostly wondering why it took
so much longer to pull all features/attributes, where index optimisation
would not have any effect.  Was the database server running on the same
box as MapGuide?  I'd also like to see what happens with some attribute
filters against a database that has proper column indexes created on it.
 
What I found most interesting though is that you're working on some
commandline tools for FDO.  That is something that is sorely needed.  An
fdo2fdo tool would be nice too.  Does Mateusz know that you're working
on this?  He was looking for some schema-ized data to test the PostGIS
provider against a couple days ago and I didn't have any.  I'd also love
to see the same kind of performance comparisons run against the PostGIS
provider when it's available, and some profiling run against the code to
see where most of the time is being spent (in fdo, network, or
database).
 
Jason
 
P.S. This kind of comparison might be OK if you are comparing the King
provider's performance against the SDF provider's performance, but be
careful about publishing performance tests for Oracle.  Their corporate
lawyers don't like this kind of thing at all.  Apparently there's a
clause in the EULA...


  _____  

From: Haris Kurtagic
Sent: Sunday, October 29, 2006 13:58
To: users at mapguide.osgeo.org
Subject: [mapguide-users] perfomance test


Test case 1: No geometry filter, Fetch all attributes 
 
SDF        0.937 
SHP        8.531 
10GR2    18.172
XE            18.500
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20061106/3b6ef047/attachment.html