Hello! TL;DR: my attempt at optimizing a program using Seq instead of List ended up using 3 to 4 times the memory, and I don’t understand why… I’m currently trying to optimize some code that seems to eat a lot of memory for some reason. I noticed that code has several List.map and List.filters do…

[image] giltho: But then what’s the point of Seq ? Don’t ask me I was against its inclusion (but for other reasons). More seriously the point versus lists is that if your data is streamable, the whole program run may allocate more but at every given point in time your program may have a smal…

@pveber flambda would definitely be an improvement, but Seq should allocate more than Lists in any case ? @SkySkimmer , I think the order is correct, I’m using it like the pipe operator

I mean shouldn’t it be non-rev? Seq.map preserves the order AFAIK Of course that means you need to decide what tailrec List.map to use :wink:

Ah sorry. Yes, the results of both tests are reversed. If you reduce size to something that List.map can work with like 200000, and use List.map instead of List.rev_map, results are the same : seq uses 1.48GB, list uses 450M

Update about flambda : Using the example with List.map instead of List.rev_map, size = 200000 and flambda the results are not very different : 1.36GB for seq (1.48GB without flambda) 435M for list (450M without flambda)

Memory usage for a lazy data type like Seq.t shouldn’t be affected by flambda–I think what’s happening here is that you’re loading the entire seq into memory immediately because you’re building it from a list. And a fully-loaded seq actually takes more memory than its equivalent list. EDIT: when yo…

Hmmm… I understand that Seq.unfold would be definitely more efficient than List.init. However, in both cases the list is allocated fully. Then I would expect Seq.map to not reallocate the intermediate steps. I’m in the exact case described in the article… so if that is true I’m guessing the article…

ok, yeah, I can definitely see that being true…But then what’s the point of Seq ? There’s 3 times the allocation so it uses more memory and also probably takes more time (although on my example it seems to take more or less the same time)…

Ahhh, then that makes it clear :slightly_smiling_face: Thank you very much for your answers !

Alternatively, you could avoid doing roundtrip to lists and write your code as you naturally would: module WITH_SEQ = struct let init n f = OSeq.init ~n f (* taken from Oseq because I'm lazy, the code is trivial *) let ( >| ) o f = Seq.map f o let sum = OSeq.fold_left (+) 0 end module WITH_L…

Seq vs List, optimization

Learning

dbuenzli November 30, 2020, 10:36pm 14

I’m too lazy to work out the details but maybe if you do it won’t be so surprising. In lists you just have one cons cell per list element, in seq you get a cons cell + a closure, so you can expect more will be allocated by processing with Seq.

1 Like

When to use list, and when to use Seq.t?

Topic		Replies	Views
When to use list, and when to use Seq.t? Learning	4	225	March 9, 2026
Recommended patterns and techniques for Seqs (especially when memoized) Learning lazy , seq , memoization	13	549	January 27, 2025
Module 'Stream' removed from 5.0 standard library? Ecosystem	62	4218	August 3, 2022
A new List.map that is both stack-safe and fast Community article , performance	34	12911	February 24, 2018
Sequences: two schools of thought? Learning	30	1522	March 9, 2024

Seq vs List, optimization

Related topics