Darwinian data structure selection

My coauthors and I used a nigh-identical technique [1] (see Section 2 Implementation) in 2015 to:

1. Optimize the Guava library for energy consumption, 2. By varying the implementations of data type interfaces, 3. Using a genetic algorithm, 4. and our results were presented in SSBSE 2015 and published in the conference proceedings.

Two years later, Basios et. al presented at the very same conference [2], where they

1. Optimize the Guava library for memory consumption, 2. By varying the implementations of data type interfaces, 3. Using a genetic algorithm, 4. and their results were presented in SSBSE 2017 and published in the conference proceedings.

I am overjoyed that Basios et al. managed to take this technique so far, and that they obtained such impressive results. I am disappointed, however, that our work still goes completely uncited and unacknowledged in their papers. Given that it involved the same library, the same techniques, the same family of algorithms and the same conference, this simply could not have slipped through the cracks of any literature review - especially since one of the authors was present and interacted with us at SSBSE 2015. I'd be happy to hear any explanation for this omission.

[1] https://link.springer.com/chapter/10.1007%2F978-3-319-22183-... [2] https://link.springer.com/chapter/10.1007/978-3-319-66299-2_...

At first glance Artemis seemed like a perfect way to overfit your benchmark as it critically depends on the versatile test suite and not much else. But thinking again, it still might be used to give a list of candidate fixes which can be reviewed and applied by human developers later. Zero-configuration invocation looks quite impressive in this regard.

I do find this interesting because many code bases I have seen use collections in the wrong way.

What could help many developers though is if an SDK would provide a factory like

    List.new[FastIndex, FastInsert]

and check at compile time if such a list can be found that satisfies all constrains (ArrayList, LinkList, CopyOnWriteList, HashSet, ...).

Currently most SDK leave this to the developer, who than mostly uses whatever he knows best and likes, say ArrayList.

(Unrelated a company should have an explantation when to use List, Seq and what in interfaces).

It would be interesting to see Artemis applied to an open source compiler or some other large project.

I wonder if the Artemis system has bounds on project size that it can handle, and where non-intuitive DDS optimizations could be made that actually improve a large scale problem. One could suppose that large projects have advanced test suites, so the fitness function should be fairly accurate, if the supposition is true.

Looks interesting with a big but:

> results will only apply to production use cases to the extent that your test suite mirrors production usage

No actual links to Artemis? How do I use this?

Wouldn't it be simpler (better?) to fit a performance model like e.g. linear regression with pairwise interactions and then do bayesian optimization?