< bitcoin-git>
bitcoin/master fafa064 MarcoFalke: ci: Remove ccache requirement on the host
< bitcoin-git>
bitcoin/master facc0da MarcoFalke: travis: Run unit and functional tests on native arm
< bitcoin-git>
bitcoin/master def69e5 MarcoFalke: Merge #17233: travis: Run unit and functional tests on native arm
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17233: travis: Run unit and functional tests on native arm (master...1910-travisNativeArm) https://github.com/bitcoin/bitcoin/pull/17233
< bitcoin-git>
[bitcoin] theStack opened pull request #17363: test: add "diamond" unit test to MempoolAncestryTests (master...20191104-test-add_diamond_ancestors_unit_test) https://github.com/bitcoin/bitcoin/pull/17363
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #17364: Updated appveyor config for VS2019 and Qt5.9.8 (master...vs2019_oct31) https://github.com/bitcoin/bitcoin/pull/17364
< instagibbs>
#17304 looks mergeable
< gribble>
https://github.com/bitcoin/bitcoin/issues/17304 | refactor: Move many functions into LegacyScriptPubKeyMan and further separate it from CWallet by achow101 . Pull Request #17304 . bitcoin/bitcoin . GitHub
< bitcoin-git>
bitcoin/master b4cb18b Andrew Chow: MOVEONLY: Reorder LegacyScriptPubKeyMan methods
< bitcoin-git>
bitcoin/master 533d8b3 Andrew Chow: Refactor: Declare LegacyScriptPubKeyMan methods as virtual
< bitcoin-git>
bitcoin/master acedc5b Andrew Chow: Refactor: Add new ScriptPubKeyMan virtual methods
< bitcoin-git>
[bitcoin] laanwj merged pull request #17304: refactor: Move many functions into LegacyScriptPubKeyMan and further separate it from CWallet (master...wallet-box-pr-3) https://github.com/bitcoin/bitcoin/pull/17304
< bitcoin-git>
[bitcoin] icota opened pull request #17365: depends: update README.md with working Android targets and API levels (master...update-android-depends-doc) https://github.com/bitcoin/bitcoin/pull/17365
< achow101>
\o/
< fanquake>
achow101 18 out of how many commits left in the wallet refactor pipeline?
< achow101>
20?
< provoostenator>
rebase time!
< achow101>
we'll find out after rebase :)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #17366: test: Reset global args between test suites (master...1911-testResetGlobals) https://github.com/bitcoin/bitcoin/pull/17366
< bitcoin-git>
bitcoin/master 090b75c User: p2p: Avoid allocating memory for addrKnown where we don't need it
< bitcoin-git>
bitcoin/master a552e84 User: added asserts to check m_addr_known when it's used
< bitcoin-git>
bitcoin/master b6d2183 User: Minor refactoring to remove implied m_addr_relay_peer.
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17164: p2p: Avoid allocating memory for addrKnown where we don't need it (master...addr_relay_optimization_4) https://github.com/bitcoin/bitcoin/pull/17164
< bitcoin-git>
bitcoin/master fa07b8b MarcoFalke: test: Reset global args between test suites
< bitcoin-git>
bitcoin/master 33b155f MarcoFalke: Merge #17366: test: Reset global args between test suites
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17366: test: Reset global args between test suites (master...1911-testResetGlobals) https://github.com/bitcoin/bitcoin/pull/17366
< bitcoin-git>
[bitcoin] fanquake opened pull request #17368: cli: fix -getinfo output when compiled with no wallet (master...fix_getinfo_no_wallet) https://github.com/bitcoin/bitcoin/pull/17368
< jeremyrubin>
Ok there *is* something very peculiar going on with trusty tahr
< jeremyrubin>
It kinda seems like the default bucket count for a newly created map is 11
< sipa>
unordered_map ?
< jeremyrubin>
yeah
< sipa>
is that unreasonable?
< jeremyrubin>
Yeah
< jeremyrubin>
I think for most others the default is 1 or 0
< phantomcircuit>
jeremyrubin, that doesn't seem that unreasonable to me?
< jeremyrubin>
It is
< jeremyrubin>
Because it means you always allocate I think
< phantomcircuit>
ok why
< jeremyrubin>
so just creating a std::unordered_set on the stack makes an allocation
< jeremyrubin>
the ones that default to 0 or 1 do so via an optimization for a single pointer case IIRC
< phantomcircuit>
yes presumably virtually every user of std::vector ends up allocating at least 11 elements
< phantomcircuit>
which would reduce malloc churn
< jeremyrubin>
Well it sucks for things like computing the DynamicUsage
< jeremyrubin>
Because you can't tell if the buckets are stack or heap
< jeremyrubin>
and so there is no x-platform way to count that memory
< jeremyrubin>
without double counting
< jeremyrubin>
And no, I think a lot of vectors stay empty
< jeremyrubin>
There's probably an interesting distribution....
< bitcoin-git>
[bitcoin] achow101 opened pull request #17369: Refactor: Move encryption code between KeyMan and Wallet (master...wallet-box-pr-4) https://github.com/bitcoin/bitcoin/pull/17369
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #17370: doc: Update doc/bips.md with recent changes in master (master...1911-docBips) https://github.com/bitcoin/bitcoin/pull/17370
< sipa>
jeremyrubin: generally vectors only allocate when you add something to them
< sipa>
and std::unordered_map needs an allocation per element anyway, afaik
< sipa>
in addition to the allocation of the table
< jeremyrubin>
Yes, but usually you wouldn't allocate the table ahead of adding anything
< jeremyrubin>
you would wait for an explicit reserve
< jeremyrubin>
Or an insert
< jeremyrubin>
It's weird to assume the user wants an allocation
< sipa>
jeremyrubin: btw, i'm working on a PR to add a memory-accounting allocayot
< sipa>
*allocator
< jeremyrubin>
That should help solve this
< sipa>
which will compute DynamicUsage exactly, regardless of what weird policy containers use
< jeremyrubin>
The only "issue" with that is then you're talking an extra 8 bytes per thing that has a map
< jeremyrubin>
And possibly, if you specify a "non static" (not sure right term) you might be paying for another extra pointer for the allocator
< jeremyrubin>
So might be good to figure out if there's a way that the templates can know which allocator they are using at compile time, and perhaps share it across multiple instances of the same inner class
< sipa>
sure, that's possible, but i think it's overkill
< sipa>
you have a pointer to a tracker size_t as template argument, for example
< sipa>
*can
< jeremyrubin>
only if it's on the stack right?
< sipa>
hmm?
< sipa>
it needs to be known at compile time, so it'd need to scoped similarly as the container definition
< jeremyrubin>
I mean that it would be difficult to pass such maps around as the template args would differ
< jeremyrubin>
yeah
< sipa>
yes
< luke-jr>
emilengler: BIP 179: next is wait for Travis ;)
< sipa>
but it could be on the heap in case the container is on the heap too
< sipa>
in any case, not worth it imho
< bitcoin-git>
[bitcoin] achow101 opened pull request #17371: Refactor: Require scriptPubKey to get wallet SigningProvider (master...wallet-box-pr-5) https://github.com/bitcoin/bitcoin/pull/17371
< bitcoin-git>
[bitcoin] achow101 opened pull request #17373: wallet: Various fixes and cleanup to keypool handling in LegacyScriptPubKeyMan and CWallet (master...wallet-box-pr-6) https://github.com/bitcoin/bitcoin/pull/17373
< bitcoin-git>
[bitcoin] achow101 opened pull request #17374: IsMine: Set state to WATCH_ONLY if we can get the pubkey (master...wallet-box-pr-7) https://github.com/bitcoin/bitcoin/pull/17374