4 ms·

Line numbers in less(1) or GitHub. Row numbers in Excel, Pandas, R, etc. The most common way to label rows is with sequential numbers.

eesmith 9y ago
FWIW, in a file with 1,000,000 lines, the best-of-3 time for "less filename > /dev/null" is: 2.508u 0.152s 0:02.66 99.6% 0+0k 0+0io 0pf+0w and the best-of-3 time for "less -N filename > /dev/null" is: 2.568u 0.159s 0:02.73 99.2% 0+0k 0+0io 0pf+0w That is, it doesn't seem like printing sequential is the limiting factor in performance. This is with "less 458", "Copyright (C) 1984-2012". I downloaded and compiled stock 487 and the best-of-3 times went up to 0:02.94 for both cases. Checking the source code, it does not appear to use knowledge of the previous output index in order to save time. The relevant code is: static int iprint_linenum(num) LINENUM num; { char buf[INT_STRLEN_BOUND(num)]; linenumtoa(num, buf); putstr(buf); return ((int) strlen(buf)); } where #define TYPE_TO_A_FUNC(funcname, type) \ void funcname(num, buf) \ type num; \ char *buf; \ { \ int neg = (num < 0); \ char tbuf[INT_STRLEN_BOUND(num)+2]; \ register char *s = tbuf + sizeof(tbuf); \ if (neg) num = -num; \ *--s = '\0'; \ do { \ *--s = (num % 10) + '0'; \ } while ((num /= 10) != 0); \ if (neg) *--s = '-'; \ strcpy(buf, s); \ } TYPE_TO_A_FUNC(linenumtoa, LINENUM)
- blt 9y ago
  hmm, maybe someone can get a pull request for implementing this optimization :)
  - eesmith 9y ago
    While I know you meant that comment in jest, it suggests that I wasn't clear enough. My implicit argument is that there's there's no reason to believe that line counting adds anything more than trivial overhead to the less output, so there's no reason to even consider this optimization, much less getting to the point to make a pull request.

eesmith 9y ago

FWIW, in a file with 1,000,000 lines, the best-of-3 time for "less filename > /dev/null" is: 2.508u 0.152s 0:02.66 99.6% 0+0k 0+0io 0pf+0w and the best-of-3 time for "less -N filename > /dev/null" is: 2.568u 0.159s 0:02.73 99.2% 0+0k 0+0io 0pf+0w That is, it doesn't seem like printing sequential is the limiting factor in performance. This is with "less 458", "Copyright (C) 1984-2012". I downloaded and compiled stock 487 and the best-of-3 times went up to 0:02.94 for both cases. Checking the source code, it does not appear to use knowledge of the previous output index in order to save time. The relevant code is: static int iprint_linenum(num) LINENUM num; { char buf[INT_STRLEN_BOUND(num)]; linenumtoa(num, buf); putstr(buf); return ((int) strlen(buf)); } where #define TYPE_TO_A_FUNC(funcname, type) \ void funcname(num, buf) \ type num; \ char *buf; \ { \ int neg = (num < 0); \ char tbuf[INT_STRLEN_BOUND(num)+2]; \ register char *s = tbuf + sizeof(tbuf); \ if (neg) num = -num; \ *--s = '\0'; \ do { \ *--s = (num % 10) + '0'; \ } while ((num /= 10) != 0); \ if (neg) *--s = '-'; \ strcpy(buf, s); \ } TYPE_TO_A_FUNC(linenumtoa, LINENUM)

blt 9y ago
hmm, maybe someone can get a pull request for implementing this optimization :)
- eesmith 9y ago
  While I know you meant that comment in jest, it suggests that I wasn't clear enough. My implicit argument is that there's there's no reason to believe that line counting adds anything more than trivial overhead to the less output, so there's no reason to even consider this optimization, much less getting to the point to make a pull request.