Justin Deoliveira ha scritto: >> Nah, sorry, just noticed I was running GeoServer trunk >> on a different jdk (jdk5 whilst 1.6.x was running on jdk6). >> The results on trunk after minor optimizations and switching >> to jdk6 are: >> >> shapefile: 5 seconds >> postigis: 67 seconds >> >> So there's still a 45% slowdown to recover from. I'm >> working on it. > > Thanks Andrea, it is good to finally have numbers to work with. Not > surprising that SimpleFeatureBuilder is slow, not designed or > implemented with optimization in mind. Do you have a better idea of > where the time is being spent? I suspect it is in all the intermediate > Attribute object creation.
Well, I already managed to get it back to 46s for postgis by avoiding one level of feature creations. In the rendering chain for postgis, for reasons I still haven't investigated, there was a force coordinate system iterator, that did its job by re-creating the feature using SimpleFeatureBuilder.copy. The old code did the same, but the price for building the feature was a lot cheaper. In my checkout I changed that to create a custom SimpleFeature wrapper that just taps into the schema related calls, this avoid another run of feature building and validation and speeds up things significantly. It also means the same optimization could be performed on 2.4.x and have some benefit (rationale, the old code has two points where features gets created, my modified checkout just one and it performs the same, meaning the cost of creating a new feature is at least twice as much as creating an old one). Still some significant amount of time is spent in the original feature creation and we should have a way to avoid that. I'm having some real problems extracting useful profiles (YourKit is giving me grief) but I think we should do the following: * have simplefeatureimpl use an Object[] as a backend for its data avoiding the expensive data structure allocations * have a fast, validation free, feature creation path for the cases where we do know attributes are good. For example, how do you make an invalid feature out of a database table, given the feature type has been created by reflecting that very table structure? I also noticed that both descriptor and attributes have a userdata field that gets allocated with an HashMap on each creation. Since both of them are never used in current code, avoiding that allocation provides some benefit. I changed the code to leave the hashmap null, and the getters so that if the field is null then Collections.emptyMap is returned. Cheers Andrea ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
