Care to share your modifications? :) On Mon, Jul 30, 2012 at 2:38 PM, Jeremie Passerin <[email protected]>wrote:
> 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, >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
