Changeset b7175721


Ignore:
Timestamp:
Feb 27, 2019, 2:41:40 PM (3 years ago)
Author:
Aaron Moss <a3moss@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr
Children:
e1e3578
Parents:
11b3053
Message:

thesis: incorporate results of vector vs. list data structures investigation

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/aaron_moss_PhD/phd/experiments.tex

    r11b3053 rb7175721  
    6363The 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).
    6464
    65 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.
    66 Work is ongoing to port \CFACC{} to use these more efficient data structures.
    67 % TODO see how Thierry gets on with this
     65Another 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.
     66Porting 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.
     67The relative performance impact of this architectural difference is unclear, and thus excluded from consideration.
    6868
    6969The 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}.
Note: See TracChangeset for help on using the changeset viewer.