On Dec 17, 2010, at 11:23 AM, Howard Butler wrote: > > One area of the code that I suspect is performance sensitive, but I haven't > done a lot of profiling of, is the portions of liblas::Point that determine > where in the point's byte array to fetch the dimension from. Currently, for > fixed-schema point formats, this is likely doing unnecessary work (the point > formats are fixed and cannot change position). I will look into that and see > if my raw i/o timings match yours and if I can improve them in any way. If > you have call stacks or other profiling information, I would be excited to > see what it might show. Find me on IRC to discuss some more today if you're > interested.
Hell yes, this was sensitive. Instead of dynamically looking up the byte positions for interpreting data, I have hardcoded them (they don't change for the base PointFormat 0 ... 3), and here are the 5-run timing results. > hardcodes > > 0.37 real 0.24 user 0.07 sys > 0.32 real 0.24 user 0.06 sys > 0.32 real 0.24 user 0.06 sys > 0.32 real 0.24 user 0.06 sys > 0.32 real 0.24 user 0.06 sys > > dynamic > > 0.60 real 0.52 user 0.07 sys > 0.60 real 0.52 user 0.07 sys > 0.60 real 0.52 user 0.06 sys > 0.60 real 0.52 user 0.07 sys > 0.70 real 0.52 user 0.07 sys > Howard_______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
