Getting passwords is slow?

[dabeeeenster]

Is this as expected?

time rbw get --full "<password name>"  0.26s user 1.84s system 94% cpu 2.224 total

This is on a core i7 2020 Macbook Pro

[doy]

how many passwords do you have in your vault? on linux, with ~200 passwords in my vault, rbw get --full takes ~80ms for me. also, how are you building it? it'll definitely also be a lot slower in debug mode.

[dabeeeenster]

I have 530 passwords. I'm building with cargo install rbw.

[jakeswenson]

I also have around 570 passwords in bitwarden and getting a single password takes around 3.5 seconds

time rbw get "<password name>"  0.40s user 3.48s system 97% cpu 3.980 total

Not quite sure on the encrypted storage format of the Db yet, but maybe this is a case for an embedded database... I've been watching sled closely (probably way overkill for this project) but there are probably some improvements that could be made here.

[doy]

i'd be pretty curious to see some profiling results here before digging into options for a fix. i'd be quite surprised if the issue here is the on-disk format - it seems a lot more likely that it's something like one of the crypto libraries i'm using not having optimized implementations of certain functions on certain platforms.

[jakeswenson]

Here is a (screenshot of a) flame graph I generated of rbw ls: 80%+ of the time is spent in ttyname

(screenshot since github wont let me add the SVG)

I used cargo-flamegraph to generate this.

[jakeswenson]

Although it might not be the best idea, I was able to speed it up drastically by removing all the code in ttyname and replacing it with this:

Now timing rbw ls:

rbw ls  0.04s user 0.08s system 54% cpu 0.224 total

[jakeswenson]

Now 92% of the time is spent in decrypt_cipher which seems reasonable:

[jakeswenson]

Maybe this isn't such a bad idea: https://unix.stackexchange.com/a/450726 Has the added benefit of removing an unsafe block and the only usage of libc

[doy]

no, this is not actually correct - we are trying to pass the name of the tty to the background agent process, which is entirely independent, so if you start the agent in one terminal, lock it, and then try to unlock it from a second terminal, /dev/tty from the perspective of the agent process is not going to be a meaningful thing. i have no idea why ttyname_r would be so slow though...

[doy]

do you also get similar results if you run something like this?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
    char buf[1024];
    int err = ttyname_r(0, buf, 1024);
    if (err != 0) {
        fprintf(stderr, "%s\n", strerror(err));
        exit(1);
    }
    puts(buf);
}

[jakeswenson]

That's a weird-looking rust program ;P

Nope, that program runs almost instantly: clang code.c

 time ./a.out
/dev/ttys001
./a.out  0.00s user 0.00s system 74% cpu 0.005 total

[albakham]

For me, getting password or listing the entries is rather quick.

What I find to be slow is: after I rbw edit an entry, I exit my editor (vim/nano/whatever), and it takes several seconds before I can use my shell again.

I suppose it needs to update some things, but perhaps could it be improved? at least when no changes are made? (because for now, changes or no changes, it's always as slow)

[stevegore]

It's a shame this couldn't be reproduced. Getting passwords is painfully slow for me as well. Mind you I'm on a Mac so I appreciate I'm probably not your target audience here.

[doy]

my guess is that this is something specific to macos, but i don't have any apple machines to debug this with. if someone who does run macos wants to dig further, i'd be very grateful!

[dabeeeenster]

I'm not a rust dev I'm afraid but happy to help if its easy for me to generate debugging info that would help?

[JaCoB1123]

I was just about to write that I'm having the same problem on Manjaro. My vault is quite big with 2130 entries, so I though this might be the reason. I was using the seemingly outdated rbw-git package though and after upgrading to 1.8.3 from 1.7.1 ls and get are now much faster. Before upgrading a get would take at least 1,5 seconds and sometimes more than 5 seconds. After upgrading it's now consistently at around 0,6 seconds.

Can anyone else confirm this?

[domrim]

I was just about to write that I'm having the same problem on Manjaro. My vault is quite big with 2130 entries, so I though this might be the reason. I was using the seemingly outdated rbw-git package though and after upgrading to 1.8.3 from 1.7.1 ls and get are now much faster. Before upgrading a get would take at least 1,5 seconds and sometimes more than 5 seconds. After upgrading it's now consistently at around 0,6 seconds.

Can anyone else confirm this?

nope, i'm using rbw 1.8.3 on macOS 13.5 (22G74). rbw ... takes still about 10s per command :(

[gdw2]

Not sure this is related, but on macOS I noticed that pinentry (subprocess of rbw-agent) is running at 100% cpu all the time -- until I force close it.

[baleksa]

Not sure this is related, but on macOS I noticed that pinentry (subprocess of rbw-agent) is running at 100% cpu all the time -- until I force close it.

Same here. Voidlinux x86_64. Two pinentry subprocesses, both of which were 99% CPU reported by htop, and two CPU cores were at 99%, but there was no performance drop and fans weren't spinning. I will provide more details and possibly open an issue when I get time to examine it better.

[doy]

i think the issue with pinentry using an entire cpu is different from the issue that people were seeing earlier - i would like to fix that one too though, so let me know if you manage to reproduce it.

[pchampio]

Hello, same issue with pinentry taking 99% of CPU. After playing around, it seems that it is a pinentry-curses issue (super old issue https://dev.gnupg.org/T814 related?).
Using pinentry-tty fixes the issue.

rbw config set pinentry "/usr/bin/pinentry-tty"