Flip Documentation LibraryFlip Performance Guide

Flip Performance Guide

• About Flip Performance Guide
• Problem Description
• Refining Arms
• Refining Jobs
  • Array and Collection
  • Implementation
  • Results
• Refining Commands
• Results

Refining Jobs

This chapter exposes a more subtle optimisation related to model redundancy.

Array and Collection

Array is a container that provides explicit order of element similar to a std::list. Collection is a container that does not provides order of element explicitly and is similar to a std::set.

In the first implementation, jobs are put into an Array which is ordered by jobs position in time.

However there is a redundancy : the order information is contained both in the Array key as well as the job position. This means that if two users are inserting two jobs between the same two consecurtive jobs, one can have the situation where the randomness of Array keys makes it so that the order of element in the Array is inconsistent with the order of position job, with a probability of 0.5. This only happens on a concurrent change.

One way to avoid that is to make a validator to ensure that a transaction is going to be rejected if the order of the jobs in the Array does not follow the implicit order of jobs by their position.

Performance wise, this has the following disadvantages :

• An Array insertion, because of the key, is a bit less performant than a Collection insertion
• There is a need for a validator that will take extra time to execute
• Finally from a UX point of view, a transaction might be rejected in a strange way from the user perspective

For this reason, the Array of jobs is replaced with a Collection of jobs. If order is important for some algorithm at the controller level, this can be done through caching, with very good performances, and is exposed into the two following chapters.

Implementation

The refined model, Model3 is implemented as below :

class Model3 : public DataModel <Model3> {};

class Factory3 : public Object

{

public:

   Collection <Job>  jobs;

};

class Company3 : public Object

{

public:

   Array <Factory3>  factories;

};

Results

The bar chart below shows the time it takes to fill a document with 16 factories and various nbr of jobs (and so robots) for a total of 2 millions commands :

We can see a slight enhancement from the previous version, but this new model will also show better user experience, as there are no more potential conflicts when inserting a Job.

The next chapter, Refining Commands, exposes an important technique that brings better concurrency as well as std kind of performances.