Tim Kientzle wrote:
I've also seen a 3x speedup by using my reimplementation of pkg_add
using my package management library, libpkg (http://libpkg.berlios.de).
It is not production ready yet as if it fails partway through an
installation it won't clean up and installed files.
I *think* a good w
I've also seen a 3x speedup by using my reimplementation of pkg_add
using my package management library, libpkg (http://libpkg.berlios.de).
It is not production ready yet as if it fails partway through an
installation it won't clean up and installed files.
I *think* a good way to do this is to:
On Sun, 17 Jun 2007 09:27:32 -0700
Garrett Cooper <[EMAIL PROTECTED]> wrote:
> Your source looks very nice, but there are a few comments:
>
> 1. How do you read BDB stuff without including the BDB headers/libs?
I don't. I've only implemented enough to reimplement
pkg_{add,delete,info}. None of the
Andrew Turner wrote:
On Sat, 16 Jun 2007 21:53:06 -0700
Tim Kientzle <[EMAIL PROTECTED]> wrote:
Also, were the bottlenecks seen in pkg_delete and pkg_add, or
does it appear to be distributed across the board?
The biggest time sink in pkg_add is writing each file to a temp
dir then
On Sat, 16 Jun 2007 21:53:06 -0700
Tim Kientzle <[EMAIL PROTECTED]> wrote:
> >Also, were the bottlenecks seen in pkg_delete and pkg_add, or
> > does it appear to be distributed across the board?
>
> The biggest time sink in pkg_add is writing each file to a temp
> dir then copying it to its f
On 2007-Jun-16 23:47:51 -0700, Garrett Cooper <[EMAIL PROTECTED]> wrote:
> Tim Kientzle wrote:
>> The biggest time sink in pkg_add is writing each file to a temp
>> dir then copying it to its final location. There are a couple
...
>Hmmm.. not sure if you're referring to the temp creation of fi
Tim Kientzle wrote:
Also, were the bottlenecks seen in pkg_delete and pkg_add, or does
it appear to be distributed across the board?
The biggest time sink in pkg_add is writing each file to a temp
dir then copying it to its final location. There are a couple
of strategies for avoiding this
Also, were the bottlenecks seen in pkg_delete and pkg_add, or does it
appear to be distributed across the board?
The biggest time sink in pkg_add is writing each file to a temp
dir then copying it to its final location. There are a couple
of strategies for avoiding this (by writing the files
Tim Kientzle wrote:
As Joerg said, though, you're not likely to gain much from
this. pkg_install is almost entirely disk bound.
Going back to this particular comment, has anybody really looked
into the speed of mtree(3)? That was the next stop that I planned on
looking at after I make my ch
Quoting [EMAIL PROTECTED] (from Wed, 13 Jun 2007 14:17:18
-0700 (PDT)):
On Wed, 13 Jun 2007, Rick C. Petty wrote:
Now another question is whether the pkg_* tools can handle multiple
processes managing the ports at the same time. For the mostpart, this is
true. Without looking at the code,
...
> Sorry -- actually I meant that (along similar lines), there was a
> program with the following lines:
>
> vsystem("/bin/chmod +x %s", filename);
>
> and I replaced it with:
>
> chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH ));
>
> Probably won't yield much gain overall, but ever
I spent a lot of time recently in libarchive/bsdtar optimizing
the disk handling; I can share lots of ideas for improving
performance of disk-bound operations like this.
One thing you might find useful: libarchive has an
API for "creating things on disk," which handles a lot
of trivia (creatin
On Wed, 13 Jun 2007, Stephen Montgomery-Smith wrote:
On Wed, 13 Jun 2007, [EMAIL PROTECTED] wrote:
PS I'm looking at pkg_install and pkg_version mostly, but I'll be looking
into the other package utilities closely in the next couple weeks,
evaluating what approaches I should take in solving
On Wed, 13 Jun 2007, [EMAIL PROTECTED] wrote:
PS I'm looking at pkg_install and pkg_version mostly, but I'll be looking
into the other package utilities closely in the next couple weeks, evaluating
what approaches I should take in solving some bottlenecks with installing
packages and ports.
On Wed, 13 Jun 2007, Tim Kientzle wrote:
Next step, eliminating the linked list structure in favor or red-black
trees, maybe.
Due to the way pkg_install works, this most likely is just adding
complexity for no gain, it might actually slow it down.
Hmmm... the only thing is that it does the l
On Wed, 13 Jun 2007, Rick C. Petty wrote:
On Wed, Jun 13, 2007 at 10:23:36AM -0700, [EMAIL PROTECTED] wrote:
On Wed, 13 Jun 2007, Joerg Sonnenberger wrote:
Should I briefly lock (flock) the file when running open/fstat/fchmod then
to avoid issues? This may become a problem as pkg_*/make become
Next step, eliminating the linked list structure in favor or red-black
trees, maybe.
Due to the way pkg_install works, this most likely is just adding
complexity for no gain, it might actually slow it down.
Hmmm... the only thing is that it does the linked list traversal a
number of times per
On Wed, Jun 13, 2007 at 10:23:36AM -0700, [EMAIL PROTECTED] wrote:
> On Wed, 13 Jun 2007, Joerg Sonnenberger wrote:
>
> Should I briefly lock (flock) the file when running open/fstat/fchmod then
> to avoid issues? This may become a problem as pkg_*/make becomes more
> parallelized (another stude
On Wed, Jun 13, 2007 at 10:23:36AM -0700, [EMAIL PROTECTED] wrote:
> Should I briefly lock (flock) the file when running open/fstat/fchmod then
> to avoid issues? This may become a problem as pkg_*/make becomes more
> parallelized (another student's goals for his SoC project).
Looking does not c
On Wed, 13 Jun 2007, Joerg Sonnenberger wrote:
On Wed, Jun 13, 2007 at 11:15:52AM -0500, Rick C. Petty wrote:
Another improvement made by using stat(2)/chmod(2) over chmod(1) using
system(3) variants is the protection against malicious filenames. The
original code should have used fork/execv i
On Wed, 13 Jun 2007, Joerg Sonnenberger wrote:
On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote:
Sorry -- actually I meant that (along similar lines), there was a
program with the following lines:
vsystem("/bin/chmod +x %s", filename);
and I replaced it with:
chmod(filename,
On Wed, Jun 13, 2007 at 11:15:52AM -0500, Rick C. Petty wrote:
> Another improvement made by using stat(2)/chmod(2) over chmod(1) using
> system(3) variants is the protection against malicious filenames. The
> original code should have used fork/execv instead anyway.
To be precise, this case shou
On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote:
>
> vsystem("/bin/chmod +x %s", filename);
>
> and I replaced it with:
>
> chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH ));
Another improvement made by using stat(2)/chmod(2) over chmod(1) using
system(3) variants is the
> Sorry -- actually I meant that (along similar lines), there was a program
> with the following lines:
>
> vsystem("/bin/chmod +x %s", filename);
>
> and I replaced it with:
>
> chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH ));
Those two lines have different effects. The first
On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote:
> Sorry -- actually I meant that (along similar lines), there was a
> program with the following lines:
>
> vsystem("/bin/chmod +x %s", filename);
>
> and I replaced it with:
>
> chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXO
Danny Braniss wrote:
--Rgf3q3z9SdmXC6oT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 12, 2007 at 10:55:18PM -0700, Garrett Cooper wrote:
Another simple question (I hope):
Is there any reason why shell comm
In <[EMAIL PROTECTED]>, Garrett Cooper <[EMAIL PROTECTED]> typed:
> Alexander Leidinger wrote:
> > Quoting Garrett Cooper <[EMAIL PROTECTED]> (from Tue, 12 Jun
> > 2007 22:55:18 -0700):
> >
> >> Another simple question (I hope):
> >>Is there any reason why shell commands should be used in plac
>
> --Rgf3q3z9SdmXC6oT
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Jun 12, 2007 at 10:55:18PM -0700, Garrett Cooper wrote:
> > Another simple question (I hope):
> >Is there any reason why shell commands s
On Tue, Jun 12, 2007 at 10:55:18PM -0700, Garrett Cooper wrote:
> Another simple question (I hope):
>Is there any reason why shell commands should be used in place of a
> C command (in this case chmod via vsystem instead of the chmod(2)
> function)? It seems like the fork / exec would be more
Quoting Garrett Cooper <[EMAIL PROTECTED]> (from Tue, 12 Jun
2007 22:55:18 -0700):
Another simple question (I hope):
Is there any reason why shell commands should be used in place of a
C command (in this case chmod via vsystem instead of the chmod(2)
function)? It seems like the fork / exec
Alexander Leidinger wrote:
Quoting Garrett Cooper <[EMAIL PROTECTED]> (from Tue, 12 Jun
2007 22:55:18 -0700):
Another simple question (I hope):
Is there any reason why shell commands should be used in place of a
C command (in this case chmod via vsystem instead of the chmod(2)
function)? It
Another simple question (I hope):
Is there any reason why shell commands should be used in place of a
C command (in this case chmod via vsystem instead of the chmod(2)
function)? It seems like the fork / exec would be more expensive with
the shell command, but any area where code could be op
32 matches
Mail list logo
