Really nice guys thanks a lot for the inputs ! Just one note on Alan's code. His current method returns all the expression driven by an object not by a specific parameter. I had to slightly adapt the code to get the specific local parameter I'm looking for !
really happy, this is so fast now ! On 29 July 2012 16:49, jo benayoun <[email protected]> wrote: > Alan, you're opening a new interesting way. :) > > Alok, DOD is not a pattern but a paradigm as OOP. If you have the time to > take a look deeper at it, you will understand what I am saying when I > reject any ideas concerning further querying on the data. > > I don't remember where I've read this (and I regret), someone was > publishing simple profiling results of regular python code and was > highlighting that 70 perc of the ressources were exclusively consumed by > dictionaries and this tends to grow because people are more and more > seduced by the convenience of those objects. > By replacing those by simpler data structures or other mechanisms, speed > performances have been improved considerably as well as CPU and memory > usage (something like 2 times faster if I remember correctly). > I am really worried when reading "They may have more memory requirements, > but these days, it really is not a problem." because this is clearly for > me an excuse for developers to do code and not good code. > Personally, I don't consider educational material even from Google > engineers as a reference as it's educational. > And yes, I am capable of beating appending on hash table in worst case > with a single linked list. Look at Python C implementation to see how they > resolve collisions. > > But even considering the query as important, nothing avoid you to pass > parameter by parameter to the function to control the flow of your code. > Like that no need of any further querying. > I've done some other tests today and friday and I am surprised that your > function produce wrong results on some models (I didn't find the why yet). > But still, considering everything which has been said, here is what I got > as last results on my machine at home for a model with still thousand of > expressions and launching a search for 11 parameters of the same ppg. (some > of those parameters are driving custom operators, that's why there is only > 4 expressions). > > # INFO : jerems took 16.2187956328 and find 4 expressions. > # INFO : mine took 1.33966050716 and find 4 expressions. > # INFO : aloks took 12.9062194445 and find 0 expressions. > # INFO : alans took 0.297864204575 and find 4 expressions. > > Anyways, I think we have all our own way of coding and I respect that. > It's always a pleasure to share with you! > =) > -- Jo > > > > > > > > > 2012/7/29 Eric Thivierge <[email protected]> > >> Good stuff Alan. Thanks for the tip. Must not be reading the docs as >> thoroughly as I should. :) >> >> >> -------------------------------------------- >> Eric Thivierge >> http://www.ethivierge.com >> >> >> On Mon, Jul 30, 2012 at 8:33 AM, Alan Fregtman >> <[email protected]>wrote: >> >>> If you ever looked at how to parse the operator stack you must've seen >>> the doc page for *ConstructionHistory*: >>> >>> http://download.autodesk.com/global/docs/softimage2012/en_us/sdkguide/index.html?url=si_om/ConstructionHistory.html,topicNumber=si_om_ConstructionHistory_html >>> >>> Third paragraph under Description: >>> *"The construction history is one example of the more general concept >>> of "Connection Stack", see >>> DataRepository.GetConnectionStackInfo<http://download.autodesk.com/global/docs/softimage2012/en_us/sdkguide/si_om/DataRepository.GetConnectionStackInfo.html> >>> for >>> details."* >>> >>> >>> >>> On Sun, Jul 29, 2012 at 6:02 PM, Eric Thivierge <[email protected]>wrote: >>> >>>> Black magic! I've never even heard of that object. :( >>>> >>>> -------------------------------------------- >>>> Eric Thivierge >>>> http://www.ethivierge.com >>>> >>>> >>>> On Mon, Jul 30, 2012 at 7:32 AM, Alan Fregtman <[email protected] >>>> > wrote: >>>> >>>>> Hey guys, >>>>> >>>>> *You're all forgetting the ConnectionStack.* It tells you what's >>>>> connected under the hood. *No need to scan through all expressions in >>>>> the scene!* >>>>> >>>>> >>>>> import xml.etree.ElementTree as ET >>>>> def getExpressionsDrivenByParameter( param ): >>>>> stack = XSIUtils.DataRepository.GetConnectionStackInfo(param) >>>>> >>>>> expressions = XSIFactory.CreateObject('XSI.Collection') >>>>> xml = ET.fromstring(stack) >>>>> for conn in xml.findall('connection'): >>>>> if conn.find('type').text == 'out': >>>>> item = conn.find('object').text >>>>> if item.endswith('.Expression'): >>>>> expressions.AddItems(item) >>>>> >>>>> return expressions >>>>> >>>>> >>>>> >>>>> It took 4.5s on my laptop to find 10,752 expressions that were >>>>> pointing to one single parameter. Fast enough for ya? :) -- In a less >>>>> ludicrous use case, it's pretty much instant. >>>>> >>>>> -- Alan >>>>> >>>>> >>>>> >>>>> On Sat, Jul 28, 2012 at 11:51 AM, Alok Gandhi < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Jeremy, >>>>>> >>>>>> I missed this first time but to make it more elegant you (not a speed >>>>>> up) you can even do: >>>>>> def getExpressionsDrivenByParameter( param ): >>>>>> return PARAM_EXPR_DICT.get(param.FullName) >>>>>> >>>>>> which is exactly the same as before but cleaner code, >>>>>> >>>>> >>>>> >>>> >>> >> >
