Index: doc/theses/aaron_moss_PhD/phd/experiments.tex
===================================================================
--- doc/theses/aaron_moss_PhD/phd/experiments.tex	(revision 11b305307e0124dc26000ab7585c27ab1f4af849)
+++ doc/theses/aaron_moss_PhD/phd/experiments.tex	(revision b71757216f19fb425cb58f2c0d7c6a93dab9a91f)
@@ -63,7 +63,7 @@
 The GC could be used for memory management with few changes to the code-base, but without a substantial re-write to enforce the same ``!const! children'' discipline \CFACC{} could not take advantage of the potential to share sub-objects; without sharing of sub-objects the GC variant of \CFACC{} must do all the same allocations and deletions and garbage-collector overhead degraded performance unacceptably (though it did fix some known memory leaks introduced by failures of the existing manual memory management scheme).
 
-Another minor architectural difference between \CFACC{} and the prototype system is that \CFACC{} makes extensive use of the pointer-chasing !std::list!, !std::set!, and !std::map! data structures, while the prototype uses the array-based !std::vector! and the hash-based !unordered_! variants of !set! and !map! instead. 
-Work is ongoing to port \CFACC{} to use these more efficient data structures.
-% TODO see how Thierry gets on with this
+Another minor architectural difference between \CFACC{} and the prototype system is that \CFACC{} makes extensive use of the pointer-based !std::list!, !std::set!, and !std::map! data structures, while the prototype uses the array-based !std::vector! and the hash-based !unordered_! variants of !set! and !map! instead. 
+Porting the prototype to use the pointer-based data structures resulted in modest performance regressions, whereas preliminary results results from porting \CFACC{} to use !std::vector! over !std::list! also showed performance regressions, in some cases significant.
+The relative performance impact of this architectural difference is unclear, and thus excluded from consideration.
 
 The final difference between \CFACC{} and the resolver prototype is that, as an experiment in language usability, the prototype performs resolution-based rather than unification-based assertion satisfaction, as discussed in Section~\ref{resn-conclusion-sec}.