summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPeter Burgess <pete.burgess@isode.com>2018-07-24 15:43:55 (GMT)
committerKevin Smith <kevin.smith@isode.com>2018-07-26 13:43:37 (GMT)
commit86fb79cb628fd830232603105c115ebec0cb7bcb (patch)
tree2394330ab0b9f807f293ff2d2e2fd009dbee9592 /Swiften/Parser/PayloadParsers/PubSubEventConfigurationParser.cpp
parentd3bbd300be4480c0a3b7285c91b3b27e82ca9c2f (diff)
downloadswift-86fb79cb628fd830232603105c115ebec0cb7bcb.zip
swift-86fb79cb628fd830232603105c115ebec0cb7bcb.tar.bz2
Handle changes in the new roster model properly
The new roster was temporarily resetting the model every time there was a change, this patch sets it up properly to use beginXxxRows, endXxxRows and dataChanged instead. Test-Information: Unit test created to check the onBeginAdd and onAdded signals get called at the correct time and that data is stored properly when a JID is added. Also tested live on test server, checked what happens when the user first logs in, and when contacts log on and off. There was some concern over the new setState function, and its impact on populating the new roster on login. I ran multiple tests, swift-4 vs swift-5 with the new roster, I tested having 3000 users with and without presence in the roster, 100 users and 3000 users split into 30 groups of 100. We tested both the time to populate the roster (pre presence) and the time from login until the roster become responsive and usable. The results weren't terribly different between swift-4 and swift-5 with the new roster, and swift-5 was populating both the old and new rosters, therefore we concluded that the new roster is not causing a significant slowing down during login. Change-Id: I2aba5cbcd81296b49d36c54ee7f07453f1b2db08
Diffstat (limited to 'Swiften/Parser/PayloadParsers/PubSubEventConfigurationParser.cpp')
0 files changed, 0 insertions, 0 deletions