> On May 7, 2013 at 3:51 PM Pádraig Brady wrote:
> I'll apply the attached in a little while.
+1
Have a nice day,
Berny
> On May 7, 2013 at 2:10 PM Pádraig Brady wrote:
> It's always best to have separate changes.
> I've split the fix out (attached) with an associated test.
The patch looks fine, thanks.
Have a nice day,
Berny
On 05/07/2013 01:10 PM, Pádraig Brady wrote:
> On 05/06/2013 07:54 PM, Cojocaru Alexandru wrote:
>> On Mon, 29 Apr 2013 00:59:20 +0100
>> Pádraig Brady wrote:
>>
>>> So I reinstated the bit vector which was a little tricky
>>> to do while maintaining performance, but it works very well.
>> I think
On 05/06/2013 07:54 PM, Cojocaru Alexandru wrote:
> On Mon, 29 Apr 2013 00:59:20 +0100
> Pádraig Brady wrote:
>
>> So I reinstated the bit vector which was a little tricky
>> to do while maintaining performance, but it works very well.
> I think it works because we are avoiding a memory access
>
On Mon, 29 Apr 2013 00:59:20 +0100
Pádraig Brady wrote:
> So I reinstated the bit vector which was a little tricky
> to do while maintaining performance, but it works very well.
I think it works because we are avoiding a memory access
inside `next_item' this way.
With this patch I try to keep th
Am 28.04.2013 04:40, schrieb Pádraig Brady:
> 2. When --output-delimiter is specified, it will allocate 31 buckets.
> Even if a few ranges are specified.
Shouldn't this be "Even if only a few ranges are specified"?
Philipp
So I reinstated the bit vector which was a little tricky
to do while maintaining performance, but it works very well.
So in summary with the attached 3 patch series, the CPU
usage of the common cut path is nearly halved, while the
max memory that will be allocated for the bit vector is 64KiB.
I'll
On 04/28/2013 07:14 PM, Cojocaru Alexandru wrote:
> On Sun, 28 Apr 2013 15:04:31 +0100
> Pádraig Brady wrote:
>
>> On 04/28/2013 12:44 PM, Cojocaru Alexandru wrote:
>>> Another problem may be the merging and the call to `xrealloc' that
>>> we do at the end of `set_fields'.
>>
>> That's only calle
On Sun, 28 Apr 2013 15:04:31 +0100
Pádraig Brady wrote:
> On 04/28/2013 12:44 PM, Cojocaru Alexandru wrote:
> > Another problem may be the merging and the call to `xrealloc' that
> > we do at the end of `set_fields'.
>
> That's only called at startup so I wouldn't worry too much.
> What was your
On 04/28/2013 12:44 PM, Cojocaru Alexandru wrote:
> On Sun, 28 Apr 2013 02:51:13 +0100
> Pádraig Brady wrote:
>> So looking in detail, this central print_kth function is of most importance
>> to performance.
> I made the same conclusion as yours, see:
> http://lists.gnu.org/archive/html/bug
On Sun, 28 Apr 2013 02:51:13 +0100
Pádraig Brady wrote:
> So looking in detail, this central print_kth function is of most importance
> to performance.
I made the same conclusion as yours, see:
http://lists.gnu.org/archive/html/bug-coreutils/2012-12/msg00045.html
> I thought that your si
On 04/26/2013 05:07 PM, Pádraig Brady wrote:
> I've rebased this to master and attached.
> The rebase wasn't trivial so I might have messed up.
> The cut.pl test is now failing on master. Could you have a look.
> Also could you add a test (or just a bit of shell) to demonstrate
> which options the
On 04/26/2013 05:11 PM, Pádraig Brady wrote:
> This separate patch to simplify the print_kth() function
> by removing the comparison from it, is simple and
> has a significant perf advantage. Tests pass so I'll apply.
>
> I'll adjust the commit log to summarise the perf change,
> but I notice the
On 04/26/2013 11:49 PM, Alexandru Cojocaru wrote:
The cut.pl test is now failing on master. Could you have a look.
>>> I had no problems. Could you show me your output?
>>
>> Ah the failures are in tests I added in the meantime:
>> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=51ce
From: Pádraig Brady
> Sent: 04/26/13 07:24 PM
> To: Alexandru Cojocaru
> Subject: Re: bug#13127: [PATCH] cut: use only one data strucutre
>
> On 04/26/2013 07:52 PM, Alexandru Cojocaru wrote:
> > Hi,
> > sorry for the delay.
> >
> > From: Pádraig Brady
&
On 04/26/2013 07:52 PM, Alexandru Cojocaru wrote:
> Hi,
> sorry for the delay.
>
> From: Pádraig Brady
>> Sent: 04/26/13 04:07 PM
>> To: xo...@gmx.com
>> Subject: Re: bug#13127: [PATCH] cut: use only one data strucutre
>
>> The rebase wasn't tri
Hi,
sorry for the delay.
From: Pádraig Brady
> Sent: 04/26/13 04:07 PM
> To: xo...@gmx.com
> Subject: Re: bug#13127: [PATCH] cut: use only one data strucutre
> The rebase wasn't trivial so I might have messed up.
Hum, I had problems only with `cut.pl'.
> The cut.pl test
This separate patch to simplify the print_kth() function
by removing the comparison from it, is simple and
has a significant perf advantage. Tests pass so I'll apply.
I'll adjust the commit log to summarise the perf change,
but I notice the change isn't as great as yours on my sandybridge i3 syste
I've rebased this to master and attached.
The rebase wasn't trivial so I might have messed up.
The cut.pl test is now failing on master. Could you have a look.
Also could you add a test (or just a bit of shell) to demonstrate
which options the memory is not allocated for example.
Ideally some patho
On Sun, 09 Dec 2012 21:45:03 +0100
Jim Meyering wrote:
> Thanks for the patch.
> This is large enough that you'll have to file a copyright assignment.
> For details, see the "Copyright assignment" section in the file
> named HACKING.
Fine.
> Have you considered performance in the common case?
Cojocaru Alexandru wrote:
> Subject: [PATCH] cut: use only one data structure
>
> The current implementation of cut, uses a bit array,
> an array of `struct range_pair's, and (when --output-delimiter
> is specified) a hash_table. The new implementation will use
> only an array of `struct range_pair
>From 678c2ecfebbf7a278c14b7e6fcb815e87569cd20 Mon Sep 17 00:00:00 2001
From: Cojocaru Alexandru
Date: Sun, 9 Dec 2012 10:43:10 +0100
Subject: [PATCH] cut: use only one data structure
The current implementation of cut, uses a bit array,
an array of `struct range_pair's, and (when --output-delimit
22 matches
Mail list logo
