Philip Kaludercic wrote: > Okamsn writes: > >> Philip Kaludercic wrote: >>> Okamsn writes: >>>> Michael Heerdegen wrote: >>>>> Does changing the internal representation of streams have an effect >>>>> on the speed of the run code? >>>> >>>> I think that it does make it slower. I am trying to test it, and I think >>>> that making records is slower than making cons cells. I think that >>>> accessing the rest of the stream takes longer because the accessors >>>> created by `cl-defstruct` always perform type checking. It seems to take >>>> about twice as long when compared to naively using `car` and `cdr`. >>>> >>>> Do you think that it would be better to disable the type checking in the >>>> accessors? If so, would you please share how to do that? The manual >>>> talks about using `(optimize (safety 0))` in a declare form, but it also >>>> seems to say that it cannot be done locally for just the `cl-defstruct` >>>> usage. If it cannot be done, do think it makes sense to use >>>> `make-record` directly, along with custom function to replace the >>>> generated accessors? >>> >>> It the overhead noticeable, or just measurable? >> >> I’m not sure what counts as “noticeable”. > > I'd say that real-world code that uses stream.el gets slower. For me > the main value of synthetic benchmarks is only the speed difference in > orders of magnitude and in the number of GC interrupts. > >> ... >> >> You can see that the struct-based run times are about twice as long. I >> think this is from the extra work done by the accessors. For example, >> the type-checking is run multiple times when accessing the “first” and >> “rest” slots, because the accessors are also used in `stream--force`. > > Type checking isn't always that bad; Do you see an (easy) way to avoid > type checking from running multiple times? Please see the attached file. By setting `safety` to 0 and explicitly checking only once in `stream--force`, we can avoid the multiple checks when evaluating an unevaluated stream. That helps when going through the stream the first time, but that still leaves multiple calls to `stream--force` when iterating. I don't have any ideas for the latter. Setting safety to 0 is about 15% faster than having the accessors do type checking, but it still isn't as fast as the current cons-based implementation. From what I have tried, iterating through nested arrays seems slower than iterating through a normal list.