Notes 5, GC performance

[Bill Baxter]

bearophile wrote:
> 1) A more uniform syntax may be better, so the following can both work:
> s.sizeof
> s.typeof
> So later typeof() function can then be removed.

I wouldn't mind .typeof for variables.  But typeof() can be applied to 
an expression too.
So would you recommend we do (a+b).typeof in that case?

> 3) In thousands of functions/classes in my D libs I have code like the following; all those functions/classes scan/use keys of the given AAs (because an AA key is much more useful, with a key you can find the value, while with a value you generally can't quickly find the key).
> 
> static if (IsAA!(TyItems)) {
>   foreach (key, val; items) {
>     // key processing...
>   }
> } else {
>   foreach (el; items) {
>     // el processing...
>   }
> }
> 
> So far I haven't found a way to avoid such silly code duplication.
> Note IsAA!() is template true if the given type is an AA.
> So I think I'd like the D foreach with 1 variable to scan by default the keys of a given AA:
> foreach(key; someAA) {...}

Agreed.  This is how Python does it too.  Makes a lot more sense to me.

I think Walter's argument was that an AA is just an array with 
generalized indices.  foreach(x; array) doesn't iterate over keys (the 
numbers 0..array.length-1), so therefore foreach(x; someAA) shouldn't 
either.

I disagree, but that's what Walters's argued in the past.  They are 
similar syntactically, but the use cases are quite distinct.  I don't 
think the syntactic similarity should be put ahead of utility.

But it's a good example you bring up -- because I think it directly 
counter's Walter's argument.  His argument is that the syntactic 
similarity should be honored over functionality concerns because of 
"generic code".   And yet here you have an example of generic code where 
you are saying that adherence to syntactic similarities is actually 
causing you headaches.  So that's good evidence from real-world code 
that the generic code argument is bogus.


> 4) The syntax of a language changes the typical usage of its constructs, and it's better for such constructs to be very fit to their typical usage. In D AAs can be defined and used with a simple & short syntax, so I think people (expecially people used to scripting languages) use them quite often, even in situations where there are only few keys (while in C++ the usage of hash maps is less easy, so they are used in situations where the programmer wants to put more keys). So I think D AAs have to be quick even when there are few keys (like 6-25 keys). I have written few benchmarks for such situations (that I think are common), and now I think D AAs aren't much optimized for them.
> I already know that scanning a short array is generally faster than looking in an AA, but I think D AA implementation may be optimized a bit for the situation with few keys.
> In my benchmarks the scan of the array (to see if an item is present) is faster than the "in" AA if the arrays is less than about 18 items long, if the retrieval probability is about 1/2 and items/keys are integers.
> Adding an element to a dynamic array, with a scan to be sure it's not already present, is faster than adding an item to an AA if the number of items is less than about 180, and this is a lot!
> There are various places around too look for ideas regarding possible ways to speed up the AAs for the situations with few keys, one of such places is the implementation of Python dicts (in Python dicts are used everywhere (each variable lookup is one or more dict accesses!) so they are tuned for the situation for few keys too). If you want to look at Python dicts implementation you can look inside its C sources, in the directory Objects, the files dictnotes.txt and dictobject.c (now I can't give direct URLS). Python C sources are quite more tidy than Perl ones :-)
> 

Agreed.  Smart people have spent a lot of time benchmarking and 
improving the performance of dicts in Python.  And Python's license is 
quite liberal.
http://www.python.org/psf/license/
Basically you can do anything you want with it, but you'd probably have 
to tack on a "Portions copyright PSF" in any place where you list DMD's 
copyright info.

--bb