For what it's worth, I believe Peter's suspicion about most time functions mapping to system functions is correct.
And Frank, not to be too overconfident, but I don't think you would end up in a situation where this time dict would start to really noticeably affect performance until its size got into the millions. -Nathan On Jun 12, 2012, at 3:02 AM, "Frank Rueter" <fr...@beingfrank.info> wrote: > thanks Peter. > Sounds like I might stick with converting the database response to a > struct_time object and storing that. Then formatting it to something readable > when needing to display it and using it as-is for sorting tools by date. > > > On 12/06/12 8:06 PM, Peter Pearson wrote: >> On 12/06/12 07:37, Frank Rueter wrote: >>> hm, that subject line might get stuck in some people's spam filter. oh >>> well... >>> >>> I am storing hundreds of struct_time objects in a fairly large >>> dictionary and am wondering if it would be wiser to convert those to a >>> floating point numbers via time.mktime() first for efficiency?! The >>> dictionary is representing database content so it may grow a lot larger >>> in the future, which is why I'm keen to be efficient now rather than fix >>> things later. >> >> I don't know if this is completely relevant, but if the python >> functions map to the standard system ones, I've found in the past that >> the mktime() and localtime() C functions are quite costly if used a >> lot (in terms of CPU usage) on both Linux and OS X, so you probably >> want to only call them once for each time item if speed is your >> primary concern... >> >> Peter > _______________________________________________ > Nuke-python mailing list > Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python _______________________________________________ Nuke-python mailing list Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
