Quote - > Quote - > Quote - I think the big issue is that the python code really needs to be compiled to be faster, as code that needs to be interpreted is going to be way slower. 

The DSON importer actually uses almost no Python code. Most of the work is done by the C++ shared libs/DLLs and the geometry is loaded from OBJs as it's done traditionally in Poser. Of course we don't know exactly what's happening in the DLL and there is probably some calls to the Python Poser API to arrange things with the geometry. Keep in mind that the .duf files are compressed JSON file so they are rather verbose, plus they need to be uncompressed. Depending on the operation, this can be pretty expensive.
In general DAZ has traditionally struggled to make their code run fast, and I suspect that the DSON plugin was prepared pretty quickly with not too much concern for performance.

We can look at the timeline to get a good idea. The DSON plugin uses the new Add-On Framework that was announced by Smith Micro and myself in August at SIGGRAPH. I don't know for sure but I assume that DAZ contacted SM after that announcement and got access to the framework. 

Then DAZ released the DSON plugin in November, if I remember well. That means about three months of development. Not much, IMHO. And this is happening while they are updating Studio with other changes and bugfixes. 

That doesn't give much time to optimize things.

For what I've heard the development team at DAZ is rather slim nowadays so they are probably spread a bit thin and optimization is probably a luxury at this time.

Cheers.

I think you're mistaken on that. The very nature of how it runs initially versus subsequent runs reeks of uncompiled code of python. Subsequent runs are faster due to the caching of the python code; since the calls are common, it doesn't need to compile it again. Also thought there may not be a lot of python code, the slowness during the "projection" phase is due to the interaction of calls between python, c++ and scrolling through the collection of morphs within Genesis (back and forth between the DSON libraries) to determine what morphs are active and should be added to the clothing and which aren't. The constant communication between compiled and uncompiled portions is causing the slowness, which doesn't matter how much python code you're writing... it's what is being accessed... which is in this case would be the user interface and material room, for instance. Also the updating of subdivision since that isn't native to Poser.

If the portions of python code could be compiled, then the communication would be faster, since you would deal with libraries of compiled code, not compiled and interpreted code.

There is probably a bug in the importer where it each time something changes in the dson items, it will redo the entire set of dson items. So add an item and all the existing items are being redone - even for figures which are not related to that item.

Simple test: Add multiple genesis items. If you add 6 genesis figures with each one clothing item and one hair item, the wait will be more than 5 minutes when you add the last one.