Refactor Seaside models to improve perceived performance. #73
Conversation
|
The direct usage of tracker/sparql is now disabled by default. When using the qtcontacts-tracker backend you should run qmake with 'CONFIG += seaside-tracker' to enable it. |
| @@ -95,6 +95,10 @@ class SeasidePerson : public QObject | |||
| Q_PROPERTY(int id READ id) | |||
| int id() const; | |||
|
|
|||
| Q_PROPERTY(bool complete READ isComplete NOTIFY completeChanged) | |||
| bool isComplete() const; | |||
| void setComplete(bool complete); | |||
There was a problem hiding this comment.
I'm a bit worried about this. In what cases will a Person not be complete? Do we have to start checking complete and connecting to the signal everywhere we want to interact with a Person...?
Remember that this API is used in a lot of places, like messaging.
There was a problem hiding this comment.
It really depends on how you're using the person objects. There are basically three ways you can get a person object.
By model row; in which case the Person is guaranteed to be populated with enough data to satisfy the model roles but possibly more when returned and all additional data will be available when it is complete.
By phone number; more or less the same as by row except you can't do any lookup of the Person until the cache is fully populated which is an existing limitation.
By ID; this can be called immediately and will always return an id but the Person may be empty or partially complete at that time. The limitation here is much the same as it was before, except you're waiting for an individual Person to be populated instead of the entire data set.
Prioritize querying the minimal amount of information required to display a list of favorites on initialization so something can be presented with the smallest of delays. Once that's done basic data for the rest of the contacts can be queried so complete or filtered lists can be presented. Finally the full contact data required for individual display and editing is pulled in on demand.
While this amounts to more lines of code it is cleaner and more linear. It should also be faster as the the pure synchronization use no longer bears the overhead of filtering, each id is only ever checked againt the filter once, and most importantly it groups changes better resulting in fewer updates of any connected view.
This doesn't appear to have any measurable affect on query times, whereas querying the id through QContactManager takes around 130ms on the hardware tested.
Some compilation issues, missing optimisations and self contact filtering.
If the contact isn't in the cache it may just be delayed, return a person anyway and the data will come later.
Refactor Seaside models to improve perceived performance.
Prioritize querying the minimal amount of information required to
display a list of favorites on initialization so something can be
presented with the smallest of delays. Once that's done basic data
for the rest of the contacts can be queried so complete or filtered
lists can be presented. Finally the full contact data required for
individual display and editing is pulled in on demand.
I'm now seeing similar performance querying 1000 contacts as I was previously with 100, and favorites are available a good 1.5 to 2 seconds before that.
To get locale correct sorting you'll need to set LC_COLLATE in the environment to your locale, otherwise sorting will be done with the "C" locale.