| | |
Is one large or a few smaller dictionaries more memory efficient?
![]() |
•
•
Join Date: Mar 2009
Posts: 6
Reputation:
Solved Threads: 1
I'm writing an application that needs to store a ton of objects and some attributes.
I was wondering, based on python's inner workings, if it's more memory efficient to have one huge dictionary or many small dictionaries and then one dictionary that just references the smaller dictionaries?
Any information would be helpful.
Thanks!
I was wondering, based on python's inner workings, if it's more memory efficient to have one huge dictionary or many small dictionaries and then one dictionary that just references the smaller dictionaries?
Any information would be helpful.
Thanks!
Personally i think if your that worried about efficiency then you should try a language like C++ which is a lot faster then python anyway.
But my bet would be on the larger one as that would take up less memory on your computer then lots of smaller ones.
But my bet would be on the larger one as that would take up less memory on your computer then lots of smaller ones.
Make it idiot proof and someone will make a better idiot.
Check out my Site | and join us on IRC | Python Specific IRC
Check out my Site | and join us on IRC | Python Specific IRC
A dictionary has hashed lookup and is highly optimized in Python, since the language uses dictionaries internally too. I would go with one dictionary.
C++ has the STL map<const Key, Data> container, but I don't know if that would be any memory saving, and don't think the lookup is hashed for speed.
C++ has the STL map<const Key, Data> container, but I don't know if that would be any memory saving, and don't think the lookup is hashed for speed.
Last edited by sneekula; Mar 22nd, 2009 at 7:22 pm.
No one died when Clinton lied.
•
•
Join Date: Sep 2007
Posts: 33
Reputation:
Solved Threads: 8
Use whatever is easiest to write the code in.
Get it right. Profile; then see if you need to worry about optimisation.
Once you have a working program, you often find that optimisations are unnecessary, or, when you profile, you find that the bottleneck isn't where you thought it might be. This way you save wasted effort, and are more likely to have something working when your deadline looms.
- Paddy.
Get it right. Profile; then see if you need to worry about optimisation.
Once you have a working program, you often find that optimisations are unnecessary, or, when you profile, you find that the bottleneck isn't where you thought it might be. This way you save wasted effort, and are more likely to have something working when your deadline looms.
- Paddy.
Actually I did a bit of research a while back on how Python allocated memory. For types like lists and dictionaries, once they are created (and the space allocated), Python doesn't free the memory for the remainder of the script's lifetime, but instead holds onto it for when newer ones are created.
This would suggest that several smaller dictionaries are more efficient that one large one IF the dictionaries are not being used concurrently (ie, one is released and then another created). But for you this doesn't seem to be the case, so I would suggest that you go with one large one since it would probably be easier to manage.
This would suggest that several smaller dictionaries are more efficient that one large one IF the dictionaries are not being used concurrently (ie, one is released and then another created). But for you this doesn't seem to be the case, so I would suggest that you go with one large one since it would probably be easier to manage.
Yeah JBennet you are exactly right.
When you remove something from a list it is unallocated from memory therefore freeing that memory up for later use.
When you remove something from a list it is unallocated from memory therefore freeing that memory up for later use.
Make it idiot proof and someone will make a better idiot.
Check out my Site | and join us on IRC | Python Specific IRC
Check out my Site | and join us on IRC | Python Specific IRC
No no, you missed the point. Yes there is garbage collection, but for types like lists and dictionaries when they are garbage collected, the memory isn't actually freed, but it is kept by the interpreter (and not released back to the OS) for later use by new lists/dictionaries. The memory *is* available for use within the interpreter (so it has been garbage collected), it's just not released back to the OS.
Also note that this doesn't apply to *all* python objects (at least that's the impression I got when I read about it). Memory held by int, string, tuple objects etc. are released back to the OS when they are garbage collected.
Also note that this doesn't apply to *all* python objects (at least that's the impression I got when I read about it). Memory held by int, string, tuple objects etc. are released back to the OS when they are garbage collected.
Last edited by scru; Mar 23rd, 2009 at 7:17 pm.
![]() |
Other Threads in the Python Forum
- Previous Thread: Recursive function
- Next Thread: Get chat text from a window
| Thread Tools | Search this Thread |
alarm assignment avogadro beginner bluetooth character cipher cmd code customdialog cx-freeze data decimals dictionary directory dynamic error examples exe file float format function generator getvalue gnu graphics gui halp homework http ideas import input ip itunes java keycontrol leftmouse line linux list lists loop maintain maze millimeter module mouse mysqldb number numbers output parsing path port prime programming projects push py2exe pygame pyglet pyqt python queue random recursion schedule screensaverloopinactive script scrolledtext slicenotation sqlite ssh string strings sudokusolver terminal text thread threading time tlapse tuple tutorial ubuntu unicode urllib urllib2 variable variables ventrilo verify vigenere web webservice wikipedia wxpython xlib






