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/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 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 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
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
