<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 3, 2018 at 10:42 PM, Jan Schaumann <span dir="ltr"><<a href="mailto:jschauma@stevens.edu" target="_blank">jschauma@stevens.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Ramana Nagasamudram <<a href="mailto:rnagasam@stevens.edu">rnagasam@stevens.edu</a>> wrote:<br>
<br>
> Could anyone help me understand exactly how this can be more efficient<br>
> than the alternative?<br>
<br>
</span>I have never looked at this in detail, but my guess is:<br>
<br>
By not including a reference to the object, you can more easily allocate<br>
the data structures and align them at compile time. Note: the<br>
implementation is (almost?) entirely in macros, so the code is inserted<br>
as is at compile time. By not including a pointer to the object, and<br>
instead requiring the object to contain the list head struct, you also<br>
yield branchless insertion/deletion in the list: any object can<br>
dereference the next item in the list without having to check the<br>
reference on the object.</blockquote><div><br></div><div>How is it branchless? You still have to check whether the next pointer is null.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The lack of pointers to the object within the list structure ought to<br>
make memory allocation more efficient, which for the purposes of the<br>
slist per the header comments and queue(3) description is desirable.<br>
<br></blockquote><div><br></div><div>I think this is the only advantage. Instead of 2 memory allocations (the sl_node and the datum), you just need 1.</div><div><br></div><div>-- Ben Iofel<br></div></div><br></div></div>