Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=GROUP_PRO_LIB_PERFORMANCE_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

The goal of this group of tasks is to improve the performance of the ProLib.
This revision of the task is responsible for improving the performance of ProLists.

Task requirements

There are too many notifications for updates when using a ProList.

Currently, when an AutoProperty depends on a ProList, it gets recomputed every time anything about the ProList changes - its size, its elements, etc. In certain cases, though, an AutoProperty might depend only on the size of a given ProList and thus in doesn't need to get recomputed when some elements in the ProList change their value, because this operation doesn't change the size of the list.

Another case is when you deal with skins. Skins are basically maps between keys and values. At a certain time an AutoProperty might be interested to monitor only the list of all pairs of keys and values which have the key "meddle". So if this list remains the same while the whole ProList which contains it changes, this AutoProperty shouldn't get recomputed.

• Devise and implement a concept how to deal with such problems.
• Refactor ProList, BaseProList and ListEntry code to fix design issues from previous tasks.
• Refactor all client code to meet new implementation.
• Think of tests which measure new performance against the current.

Task result

• New functionality code
• Nice unit tests

Implementation idea

Introduce aspects.

Related

PRO_LIB_MODEL_PRO_LISTS_R0

How to demo

• Show previous unit tests don't break
• Show performance improvement

Design

Refactoring of code written in previous tasks will be done like this:

• ListEntry will become an Immutable to prevent users from modifying the key or value of a ListEntry which has been added to a ProList (basically, just stick to the rule that our goal in Sophie is to deal with either Immutables or ProObjects)
• findAll() and findOne() methods of the ProList<E> interface will now return List<E> and E respectively, not List<ListEntry> and ListEntry.
• the internal indexing Map in BaseProList and the corresponding methods for manipulating it will be refactored in sync with the above two design changes

Solving the notification issues will be accomplished with the introduction of Aspects:

• an Aspect is a Pro, so listeners can be attached and detached to/from it. Also, it has a ChangeManager which will keep track of its Changes.
• BaseProList will use Aspects internally to reduce the attached listeners and the registered reads. This way:
  • lots of reads should be registered with the ProList itself but with an Aspect of the ProList, and so lots of listeners will be attached to the Aspects, instead of the ProList
  • ProChanges will be fired from the Aspects ...
• the internal list which actually holds the elements in a ProList is the CacheList. Its access and mutator methods register reads to the whole ProList. Instead of doing this

Implementation

^{(Describe and link the implementation results here (from the wiki or the repository).)}

Testing

^{(Place the testing results here.)}

Comments

^{(Write comments for this or later revisions here.)}