Christoph Zwerschke wrote: > Fredrik Lundh wrote: > > I'll repeat this one last time: for the use cases presented by Zwerschke > > and "bonono", using a list as the master data structure, and creating the > > dictionary on demand, is a lot faster than using a ready-made ordered > > dict implementation. if you will access things via the dictionary a lot, > > you can cache the dictionary somewhere. if not, you can recreate it > > several times and still get a net win. > > You're right in pointing out that the advantage of ordered dictionaries > (unless you use an omptimized C implementation) is not a performance gain. > > But please see my other reply: If the dictionary has more than 3 items > (say 10 or 20), and an effective ordered dict is used, it's not really > "a lot" slower. At least if we are talking about a situation were "on > demand" is "always". So, on the other side there isn't such a big > performance loss when using ordered dictionaries as well. > > The advantage of using an ordered dictionary is that you can set up your > ordered dictionary (say, describing your database columns) once, and > then can access it in any way you like in the following: Iterate over it > in a guaranteed order or access item, always refering to the same > object, without needing to care about building and caching auxiliary > objects with different names depending on what you are doing. > Well, I don't think performance is the concern(at least not for me), but how best to blend with the rest of the code which I have no interest to explain as I am not here to convincing anyone for such a thing. I just present a use case, if they see it, fine. If not, that is fine too.
But I did learn something that creating a dict on a list cost me nothing, I would be less worry about the performance hit in the future. -- http://mail.python.org/mailman/listinfo/python-list
