Re[2]: Major change proposal
Lenard Lindstrom <[email protected]> Fri, 6 Aug 2004 08:25:54 -0700 (Pacific Daylight Time)
| Newsgroups | gmane.comp.lang.prothon.user |
|---|---|
| Message-ID | <Mahogany-0.66.0-4294695193-20040806-093904.00@pop3.norton.antivirus> |
On Thu, 5 Aug 2004 10:28:46 -0700 Mark Hahn <[email protected]> wrote: > Lenard Lindstrom wrote: > > > For me one of the big concerns with Prothon is performance. Calculating > the > > C3 resolution order for each attribute lookup is going to be expensive. So > > I am curious as to how well Lieberman's caching scheme will work. I > believe > > the effectiveness of the cache, more than anything, will determine the > ultimate > > fate of Prothon. If prototypes turn out to be too expensive then they will > > be regarded as a specialty tool. So will .Net support the cache? > > Yes, this is a big concern. .Net has a lot of special collection types like > hash tables and dictionaries. I'm just crossing my fingers that one of > these will work well for my cache. > That answers one question I had. .Net will be used exclusively. No external C modules implementing Prothon specific objects. > My biggest concern in this area right now is that I am going to give up my > object locking. I was going to use that for intelligent cache invalidation. > Lieberman claims in his paper that a dumb scheme will work well. I guess I > will find out. > > By the way, Guido was commenting over the weekend that he was never > convinced the extra work for C3 was really needed. The 2.2 scheme was > pretty good. As long as you document your scheme a programmer can live with > it. Of course he also said he thought multiple inheritence was never really > needed either. > Giving it more thought I wonder just how much extra impact recalculating C3 will have. I am only familiar with it in its Python form. It is the recursion that looks intimidating. The C version may be coded more efficiently. Also most inheritance is single. So this may make the algorithm trivial in this case. And as you mention above C3 may even be overkill. Besides mro calculation is only a small part of the attribute lookup process. If you are not already aware of it Python attribute lookup is complicated. I do not think Prothon is any worse. Where there is a difference is in variable lookup. The Python compiler can replace local variable names with index positions in most cases. But I do not see why this is not possible in Prothon as well. Lenard Lindstrom <[email protected]>