Opened 11 years ago
Closed 10 years ago
#28 closed defect (wontfix)
Table Data Master Ticket
Reported by: | Scooter Morris | Owned by: | Conrad Huang |
---|---|---|---|
Priority: | blocker | Milestone: | Core API Complete |
Component: | Core | Version: | |
Keywords: | Cc: | chimera-programmers | |
Blocked By: | Blocking: | ||
Notify when closed: | Platform: | all | |
Project: | chimera |
Description
Change History (3)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Well, Chimera 1 already uses tabular data in a number of circumstances, including ViewDock and Modeller to name two. Having a core table data structure that knew how to serialize itself would simplify the session save/restore of these tools and probably others also.
comment:3 by , 10 years ago
Component: | Table Data → Core |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
My understanding is that a main motivation for using a table data structure is memory efficiency compared to using Python object attributes which are stored in a Python dictionary. In our Chimera meeting discussion yesterday we talked about how Python "slots" allow creating Python objects without an attribute dictionary. The memory savings mentioned on the web using slots is about 30-50%. I think that memory savings is not worth any added code complexity because it is not enough for dealing with the main memory hogs, Python atom and bond objects. As we've discussed previously, those can be dealt with by not creating Python atom/bond objects, and instead working only with sets of atoms and bonds in code that we want to have high performance. The sets would have methods implemented in C++ to avoid loops over atoms/bonds in Python. A tool that does loop over Python atoms/bonds would benefit by using less memory using slots, but I think this second tier optimization is not a high priority.
It would be useful for someone to list the benefits of Tables beyond potential memory efficiency.