The `getaddressesbylabel` API spends a lot more time than the `getaddressesbyaccount` API.

I generated addresses by the `getnewaddress` API, then, I measured time that the `getaddressesby*` API spends. It seems the algorithm of the `getaddressesbylabel` API takes **O(N ^ 2)** time! The results of my survey are as follows.

### getaddressesbylabel

bitcoind v0.17.1 on Ubuntu 16.04 (AWS EC2 t3.large)

#### 11,001 addresses

```sh
time sudo /usr/local/bin/bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getaddressesbylabel ""
# (omitted)
real    0m1.230s # 1.2s
user    0m0.044s
sys 0m0.048s
```

#### 111,001 addresses

```sh
time sudo /usr/local/bin/bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getaddressesbylabel ""
# (omitted)
real    1m37.027s # 97.0s
user    0m0.408s
sys 0m0.544s
```

#### 211,001 addresses

```sh
time sudo /usr/local/bin/bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getaddressesbylabel ""
# (omitted)
real    6m3.727s # 363.7s
user    0m0.800s
sys 0m0.900s
```

### getaddressesbyaccount

bitcoind v0.16.3 on Ubuntu 16.04 (AWS EC2 t3.large)

#### 11,001 addresses

```sh
time sudo /usr/local/bin/bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getaddressesbyaccount ""
# (omitted)
real    0m0.500s # 0.5s
user    0m0.092s
sys 0m0.160s
```

#### 111,001 addresses

```sh
time sudo /usr/local/bin/bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getaddressesbyaccount ""
# (omitted)
real    0m1.361s # 1.4s
user    0m0.168s
sys 0m0.348s
```

#### 211,001 addresses

```sh
time sudo /usr/local/bin/bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getaddressesbyaccount ""
# (omitted)
real    0m2.220s # 2.2s
user    0m0.384s
sys 0m0.532s
```

{
                            {"confTarget", RPCArg::Type::NUM,  "fallback to wallet's default", "Confirmation target (in blocks)"},
                            {"totalFee", RPCArg::Type::NUM,  "fallback to 'confTarget'", "Total fee (NOT feerate) to pay, in satoshis.\n"
            "                         In rare cases, the actual fee paid might be slightly higher than the specified\n"
            "                         totalFee if the tx change output has to be removed because it is too close to\n"
            "                         the dust threshold."},
                            {"replaceable", RPCArg::Type::BOOL,  "true", "Whether the new transaction should still be\n"
            "                         marked bip-125 replaceable. If true, the sequence numbers in the transaction will\n"
            "                         be left unchanged from the original. If false, any input sequence numbers in the\n"
            "                         original transaction that were less than 0xfffffffe will be increased to 0xfffffffe\n"
            "                         so the new transaction will not be explicitly bip-125 replaceable (though it may\n"
            "                         still be replaceable in practice, for example if it has unconfirmed ancestors which\n"
            "                         are replaceable)."},
                            {"estimate_mode", RPCArg::Type::STR,  "UNSET", "The fee estimate mode, must be one of:\n"
            "         \"UNSET\"\n"
            "         \"ECONOMICAL\"\n"
            "         \"CONSERVATIVE\""},
                        },
                        "options"},
                },
                RPCResult{
            "{\n"
            "  \"txid\":    \"value\",   (string)  The id of the new transaction\n"
            "  \"origfee\":  n,         (numeric) Fee of the replaced transaction\n"
            "  \"fee\":      n,         (numeric) Fee of the new transaction\n"
            "  \"errors\":  [ str... ] (json array of strings) Errors encountered during processing (may be empty)\n"
            "}\n"
                },
                RPCExamples{
            "\nBump the fee, get the new transaction\'s txid\n" +