[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.4.1-88-g46ffd34
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via 46ffd342a4255916a9599692b5969ae4cd85a156 (commit)
via fa933df65b9e024ec3291fcc1f995be3dc000e0c (commit)
via 67068b64b9da96a0122591ede25c50ab307a1612 (commit)
via 73442a7e035a7b7f8ed80261226989ae87edd3a9 (commit)
via 1e0e5b2a0241d1f3e298991c0d583afb9c80baef (commit)
via dff73a2a69de1c55a0ba9fe75a9f7a900e5ed15b (commit)
from bef19a266bf5d80b68cab02f6a3ccc3fcedbec6d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 46ffd342a4255916a9599692b5969ae4cd85a156
Author: Jakob Gruber
On 12/10/10 01:33, Dan McGee wrote:
commit dff73a2a69de1c55a0ba9fe75a9f7a900e5ed15b Author: Dan McGee
Date: Tue Oct 5 11:44:32 2010 -0500 Avoid stat call to determine is_directory if possible
On Linux and OS X, we can determine if an entry obtained through a readdir() call is a directory without also having to stat it. This can save a significant number of syscalls. The performance increase isn't dramatic, but it could be on some platforms (e.g. Cygwin) so it shouldn't hurt to use this unconditionally where supported.
Signed-off-by: Dan McGee
I thought we were dropping that one as it actually made things slowed? Allan
On Mon, Oct 11, 2010 at 5:27 PM, Allan McRae
On 12/10/10 01:33, Dan McGee wrote:
commit dff73a2a69de1c55a0ba9fe75a9f7a900e5ed15b Author: Dan McGee
Date: Tue Oct 5 11:44:32 2010 -0500 Avoid stat call to determine is_directory if possible
On Linux and OS X, we can determine if an entry obtained through a readdir() call is a directory without also having to stat it. This can save a significant number of syscalls. The performance increase isn't dramatic, but it could be on some platforms (e.g. Cygwin) so it shouldn't hurt to use this unconditionally where supported.
Signed-off-by: Dan McGee
I thought we were dropping that one as it actually made things slowed?
Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.). -Dan
On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee
Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.).
-Dan
Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
On Wed, Oct 13, 2010 at 5:36 PM, Xavier Chantry
On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee
wrote: Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.).
-Dan
Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
Yes, we will probably want to port it into that set of patches, I agree. -Dan
On 14/10/10 08:53, Dan McGee wrote:
On Wed, Oct 13, 2010 at 5:36 PM, Xavier Chantry
wrote: On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee
wrote: Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.).
-Dan
Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
Yes, we will probably want to port it into that set of patches, I agree.
Whoops! Poor rebasing on my part. I was intending to keep this iin be_local and has assumed it was... I will fix that. Allan
On 14/10/10 10:54, Allan McRae wrote:
On 14/10/10 08:53, Dan McGee wrote:
On Wed, Oct 13, 2010 at 5:36 PM, Xavier Chantry
wrote: On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee
wrote: Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.).
-Dan
Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
Yes, we will probably want to port it into that set of patches, I agree.
Whoops! Poor rebasing on my part. I was intending to keep this iin be_local and has assumed it was... I will fix that.
And it has been restored. Although the majority of it use has been removed due to not reading in the sync database via a directory list on the file system. Allan
participants (4)
-
Allan McRae
-
Dan McGee
-
dan@archlinux.org
-
Xavier Chantry