On Sat, Mar 30, 2019 at 09:04:28AM -0700, C K Kashyap wrote:
> The sample you shared certainly looks more elegant. I have a follow up
> question though - we seem to do 3 iterations in it, the main one, one for
> length and one for member. Coming to think of it, given my scenario, its
> negligible. However, in general, is this recommended - granted that it's
> still linear. I'd love to hear your thoughts on this.
It depends on the length of the list. Roughly estimated, for lists shorter than
100 or perhaps even 1000, it is still faster.
The reason is that PicoLisp is an interpreted system. The cost of calling a
(built-in) function is higher than the actually processing done in it. 'member'
takes almost negligible time compared to processing the elements on the Lisp
level with 'pop', 'inc', 'setq' etc.
You can try yourself:
(gc 8)
(bench
(let L (chop "234.45abc")
(do 10000000
(read-num 1 L) ) ) )
This takes (on my Nexus 9 tablet) 19.640 sec sec on my version and 25.700 sec on
the original one.
Thus, in general, I would say that this simple rule almost always holds:
In PicoLisp a shorter program is also faster
I often compare alternative solutions with 'size' and then go with the
smaller one.
> About 1 cell per character - if I understand correctly, that would be
> 16bytes per character on 64 bit ... does that mean that a parser written in
> PicoLisp would require 16 times more memory compared to C?
Correct, when all characters are single-byte (they may have up to four bytes per
character).
But: A Lisp program needing 16 times the memory of a C program is only the case
when all data are read into memory at once and kept there.
Typically this does not happen. Data are processed sequentially, and 'pack'ed,
'format'ed or stored in DBs or files after that. Then a C program might actually
take *more* memory, because you allocate buffers for the maximally expected size
(eg. line length), while Lisp allocates exactly only as many cells as it needs.
A worst-case example, however, is the Vip editor, which naturally keeps the
whole buffer as lists of lists of chars, and noticeably goes down in performance
for large files.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
