We should look into keeping connections open while a branch is "open" in Explorer
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar Explorer |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
ssh connections have a significant overhead, especially when connecting to an Ubuntu Jaunty box. (I don't know why new versions of Ubuntu take *longer* to connect than older ones, but I've definitely noticed the behavior.)
As such, when using a local checkout and *everything* has to connect to the remote location, Bazaar Explorer seems very slow. Even though I'm on a local network, I'm seeing 1-3s of lag to do any action, because of the time it takes to get the handshake done. (Plus even more time when you still have to enter your password.)
Something like Connection Master from openssh could be another interesting option.
http://
The ideal would be to have a single master connection opened and maintained, and then sub-connections opened whenever we actually need to do something. That way, we don't have to worry about deadlocks, or having 2 threads trying to both do something over the socket at the same time.
In the worst case, maintaining 1 connection per branch would be ok. Having to re-connect everytime you "Refresh" is just stupid slow.
Changed in bzr-explorer: | |
importance: | Undecided → High |
status: | New → Confirmed |
Changed in bzr-explorer: | |
importance: | High → Wishlist |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John A Meinel wrote:
> Public bug reported:
>
...
> The ideal would be to have a single master connection opened and
> maintained, and then sub-connections opened whenever we actually need to
> do something. That way, we don't have to worry about deadlocks, or
> having 2 threads trying to both do something over the socket at the same
> time.
>
> In the worst case, maintaining 1 connection per branch would be ok.
> Having to re-connect everytime you "Refresh" is just stupid slow.
>
> ** Affects: bzr-explorer
> Importance: Undecided
> Status: New
>
Note that a major detractor from this is that we spawn a new subprocess
for most interesting operations. (qlog, qannotate, qcommit, etc are all
separate processes.)
Not only that, but those commands then sometimes spawn *another* subprocess.
So consider the idea of:
1) I open bzr-explorer and and point it at my working tree
2) It opens the branch and connects to determine whether or not there
are local changes.
3) I then follow the 'Commit the changes' link which spawns qcommit
under the covers.
4) This then opens the working tree again to get the information it
needs about what would need to be committed. (Never mind the fact
that we already ran status in bzr-explorer...) This yet again opens
a connection to the remote branch.
5) We decide everything looks good, type our commit message and press
ok. This spawns 'bzr commit' under the covers.
6) Which yet again opens the working tree and branch, though this time
it takes out a write lock.
7) The commit finishes, returning control to bzr-explorer
8) Which then should refresh its working tree state, requiring yet
another connection to the remote repository, and another password
entry.
Which means that to start from bzr-explorer through the point of
actually committing something takes 4 prompts even if all the different
steps are not accidentally connecting multiple times.
Perhaps we can keep a connection open in bzr-explorer, but we can't
leave the working tree locked. Because when you spawn a subprocess it
eventually gets to a subprocess that needs to write-lock the working
tree so it can be updated. And that would block versus the read-lock
taken in earlier levels.... ugh
This *really* wants me to re-evaluate the idea of lightweight checkouts
and bzr-explorer. As the stack is pretty much designed to work in the
worst way possible. Even if you have an ssh-agent running, it still
requires 4 ssh handshakes. (In my testing this can be easily 1s+ each
even on the local network.)
Note that this also is triggered for pretty much all the other actions do-the- action, one for status when you get back to
you'd want to do. "bzr-explorer 'Add'" re-opens the object at least 4
times. (one for status, one for qadd dialog, one for
qadd-actually-
bzr-explorer.)
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkq wMUoACgkQJdeBCY SNAAMFPgCgv+ do5DL5dVEp4G6i1 29oWTmN fVP4GEnoBDRzqiA b8p
x5wAn3pixAjVW+
=GSJm
-----END PGP SIGNATURE-----