Closed dominictarr closed 5 years ago
Good thing I added a test for private messages to bench-ssb a few days ago :)
The tests show that it goes down to 4.3s from 4.5s before for 10k messages. Nice find.
One minor thing, this doesn't work if you pass in the private key directly, instead of the keys object.
good point. I checked my things that use it, (ssb-db and ssb-identities) patchcore also does it that way: https://github.com/ssbc/patchcore/blob/632f74ad8a65960017ff438eaf47b2e90ccd7cc8/message/sync/unbox.js#L25
also pushed a change so that it only caches the key if an object was passed in... so that shouldn't break anything by adding this change.
I'm 4.5 -> 4.3 is only 5%, that's a lot less than I was seeing on my actual log...
merged into 7.1.7
I updated the ssb stack in manyverse, and now using latest ssb-server and ssb-keys 7.1.7. However, I noticed that it's overall slower. In (very) early tests, app startup took 8 seconds compared to the previous 4 seconds. Indexing also felt slower, although I didn't measure. That said, I don't know which of these many dependency updates made it slower.
@staltz that sounds strange. What version of ssb-server and ssb-keys were you using before?
@arj03 Here's the previous package.json https://gitlab.com/staltz/manyverse/blob/32ec7e509a1d4c9a5f470836145c1a0de467c2cb/src/backend/package.json and the new one is:
{
"name": "backend",
"version": "0.0.0",
"main": "loader.js",
"engines": {
"node": "10.13.0"
},
"dependencies": {
"bindings-noderify-nodejs-mobile": "10.3.0",
"bufferutil": "4.0.1",
"cached-path-relative": ">=1.0.2",
"chloride": "2.2.14",
"delay": "3.1.0",
"estimate-progress": "1.0.0",
"flumeview-level": "3.0.13",
"ip": "1.1.5",
"multiserver-dht": "4.0.0",
"multiserver-rn-channel": "1.3.0",
"non-private-ip-android": "1.4.4-2",
"pull-cat": "1.1.11",
"pull-file": "1.1.0",
"pull-pushable": "2.2.0",
"pull-pair": "~1.1.0",
"pull-stream": "3.6.9",
"pull-thenable": "1.0.0",
"ssb-server": "15.0.1",
"ssb-about": "2.0.0",
"ssb-backlinks": "0.7.3",
"ssb-blobs": "1.2.1",
"ssb-bluetooth": "1.1.14",
"ssb-config": "3.3.1",
"ssb-contacts": "0.0.2",
"ssb-dht-invite": "1.0.0",
"ssb-ebt": "5.6.5",
"ssb-friends": "4.1.4",
"ssb-master": "~1.0.3",
"ssb-invite": "~2.1.3",
"ssb-replicate": "~1.3.0",
"ssb-local": "~1.0.0",
"ssb-keys": "7.1.7",
"ssb-legacy-conn": "1.0.25",
"ssb-mobile-bluetooth-manager": "3.2.2",
"ssb-private": "0.2.3",
"ssb-query": "2.4.1",
"ssb-ref": "2.13.9",
"ssb-serve-blobs": "2.1.0",
"ssb-threads": "3.4.0",
"ssb-typescript": "1.4.0",
"utf-8-validate": "5.0.2",
"utp-native-no-prebuild": "1.7.3-4",
"xtend": "4.0.1"
},
"devDependencies": {
"noderify": "4.1.0"
}
}
Strange. The only performance regression that I know of that should have changed (as far as I can read the old versions) is https://github.com/ssbc/ssb-validate/commit/f1dd1cd075e6f0fa6077b1f9d1f38c1502bed4af#comments but that is only 10%. That is only for validating new messages, so shouldn't have anything to do with indexing or startup performance.
Yeah, there's a lot that going on here, it could be newer versions of leveldown got slower (due to changes in native module compilation), could be some duplicate module that is blending old version with new version. Unfortunately this is why I can't "just update", it has to be a manual effort each time. Nevermind, it's off topic for this thread.
@keks and I discovered this simple change improves index building perf by 15% (on my laptop)
asymmetric operations are about 60 times more expensive than symmetric operations, and we do two of them, but this one is cachable.
@arj03 @staltz