Hey Alok, thanks for you feedback, I think you're mistaken in the interpretation of the code layout I chose tho. This is the purpose of the DOD paradigm to think about how the data should be input and how it should be treated. This would be too pretentious from me to say it has been used here, but trying to treat the data the more linearly possible is a good start, it saves memory and speed. I can bet easily, speed increases massively on yours or Jeremie's if lot more than 2 or 3 parameters are treated compared to mine. One of the effects of using DOD is you're ending by processing the data linearly which avoid any query next and make your code really fast and reactive.
About the function calls thing, I would say, that making one function call instead of many would not influence so much speed results. A function is a simple object as many other stored on the heap once created and called with arguments (other objects). There is no special initialisation nor building done each time. But even by considering this, and making my function called with xsi parameters passed one by one, this is still faster (20perc on my machine) and this for many different other reasons. If I didnt chose any dictionaries based implementations as you did, this is because the python hash table implementation is generic and use lot of memory with lost of blocks where py list are implemented as linked list and permit really fast appending, O(1). :) -- Jo 2012/7/27 Eric Thivierge <[email protected]> > Maybe something like this depending on if you use "this_model" (I dont' > recommend it as we've seen tons of expression corruptions involving this). > > collExpressions = xsi.FindObjects2(c.siExpressionID) > lTgtExprs = [x for x in collExpressions if "null.kine.local.posx" in > x.Parameters("Definition").Value] > > -------------------------------------------- > Eric Thivierge > http://www.ethivierge.com >
