Performance investigation - first on read side, then write side

[GoogleCodeExporter]

We still intend to do a round of profiling and performance investigation to 
find out where the expensive operations are. 
Some general ideas:
- would we get better performance by building a single-thread only version of 
the library to see if locking and CAS operations are hurting performance vs a 
multithread read
- What cache hit ratio would we get with real assets? Right now the read cache 
isn't usable, but if caching would give us a win, how big of a win. If the 
cache would help fixing it shouldn't be that hard
- Are there array properties that we could do something fancy with (e.g. in 
Xform we swtiched from an array to a N-dimension scalar
- Is reader code calling ctors with kWrapExisting all the time AND is that 
construction costing us lots? I think so, in which case reader code should 
construct the objects once and hold onto them until the read is completee 
(maybe the Schema isntances are too heavy, so maybe we could get fancier by 
unloading parts of the HDDF5 data structs
- More radical, but the use of HDF5 slice by object and then frame (sample). It 
might be that slicing by sample first would give faster read speed.
- Are there things we can tuen in HDF5 such as H5Pset_meta_block_size, 
H5Pset_sieve_buf_size, H5Pset_cache, H5Pset_buffer, also looks like for really 
small things (maybe xform samples < 4KB we can set layout H5D_Compact and 
alloc_time EARLY and that will do write I/O in single op.  that would affect 
our read or write performance?

Basically we have to build some test cases and then measure and profile to find 
out where the time is going.

I gave a ten day estimate, which is HUGE. I suspect we'll want to cut this into 
2 (or 3) phases and re-asses as we go.

Original issue reported on code.google.com by ble...@gmail.com on 8 Jul 2011 at 6:18

[GoogleCodeExporter]

Agreed today this would be done - please make sure estimates are accurate.

Original comment by scottmmo...@gmail.com on 11 Jul 2011 at 11:14

• Added labels: Milestone-1.0
• Removed labels: Milestone-1Disc

[GoogleCodeExporter]

Spoke with Brian L and changing this estimate to 5 days

Original comment by scottmmo...@gmail.com on 14 Jul 2011 at 3:21

• Added labels: EstimateInDays-5
• Removed labels: EstimateInDays-10

[GoogleCodeExporter]

Current thought from Shandra is that we may need to pass on this for the 1.0 
release. Will offer up question to the group and go from there. Email to be out 
to internal folks momentarily.

Original comment by scottmmo...@gmail.com on 14 Jul 2011 at 11:47

[GoogleCodeExporter]

One relatively simple test that should be looked at is creating an 
ISchemaObject from an IObject.  For our Siggraph test asset it looks like this 
casting is accounting for about 25% of the overall time it takes to initialize 
the scene in Maya.

Original comment by miller.lucas on 18 Jul 2011 at 8:10

[GoogleCodeExporter]

Thanks Lucas. We are going to hold on scheduling any time on this for now. Just 
doesn't  look like we'll have time until after SIGGRAPH.

Original comment by scottmmo...@gmail.com on 29 Jul 2011 at 1:20

• Added labels: Milestone-1.1
• Removed labels: Milestone-1.0

[GoogleCodeExporter]

Original comment by ble...@gmail.com on 19 Sep 2011 at 9:30

[GoogleCodeExporter]

Scope is too broad.
We've done a bunch of performance analysis already and have some things which 
will be added to 1.1

Original comment by miller.lucas on 25 Jun 2012 at 6:27

• Changed state: Done