Thanks Nathan,
it's for the NukeBridge I promised two years ago at Siggraph and which I
am finally re-writing, so it's about a tool browser that allows listing,
searching, filtering etc of all tools available on Nukepedia.
The dictionary represents all active tools in the database.
The dates in the dictionaries are used for display and for sorting, and
the current speed is fine (using struct_time objects).
We currently are dealing with 400+tools so I am not expecting anything
near the hundreds of thousands mark (I will be well and truly retired if
that ever happens :-D ).
On 12/06/12 7:32 PM, Nathan Rusch wrote:
While I don't have experience with this situation directly, I don't
know that it would end up making a whole lot of difference.
Both are C-types, though struct_time is 3 times the size of a float in
memory if that carries any weight in your situation. Either way, dicts
are efficient enough that I really don't think you'll run into a
problem, especially since I don't think the size of value objects
affects lookup time.
However, I don't want to assume too much about your use-case. Can you
provide any info on what you'll end up doing with these time values,
how often you update/query the dict and under what circumstances, and
whether you're worried about speed or memory efficiency (or both)? For
example, if you're going to be querying them a lot and then having to
re-cast them to a datetime or struct_time object, you'd probably be
better off storing them as such to begin with. Also, to what (rough)
upper bound would you like to bulletproof this? 250,000? 1 million? 25?
-Nathan
-----Original Message----- From: Frank Rueter
Sent: Monday, June 11, 2012 11:37 PM
To: Nuke Python discussion
Subject: [Nuke-python] performance question
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.
Does anybody have experience wit this?
Cheers,
frank
_______________________________________________
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
_______________________________________________
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
