Various minor optimizations in rb_erase():
- Avoid multiple loading of node->__rb_parent_color when computing parent
and color information (possibly not in close sequence, as there might
be further branches in the algorithm)
- In the 1-child subcase of case 1, copy the __rb_parent_color field
On Mon, Aug 6, 2012 at 1:58 PM, Peter Zijlstra wrote:
> On Mon, 2012-08-06 at 13:50 -0700, Michel Lespinasse wrote:
>> On Mon, Aug 6, 2012 at 7:21 AM, Peter Zijlstra wrote:
>> > On Thu, 2012-08-02 at 15:34 -0700, Michel Lespinasse wrote:
>> >> + /* Case 3: node's successor
On Mon, 2012-08-06 at 13:50 -0700, Michel Lespinasse wrote:
> On Mon, Aug 6, 2012 at 7:21 AM, Peter Zijlstra wrote:
> > On Thu, 2012-08-02 at 15:34 -0700, Michel Lespinasse wrote:
> >> + /* Case 3: node's successor is leftmost under its
> >> +* right
On Mon, Aug 6, 2012 at 7:21 AM, Peter Zijlstra wrote:
> On Thu, 2012-08-02 at 15:34 -0700, Michel Lespinasse wrote:
>> + /* Case 3: node's successor is leftmost under its
>> +* right child subtree
>
> Hmm?
Would 'leftmost under node's right child
On Thu, 2012-08-02 at 15:34 -0700, Michel Lespinasse wrote:
> + /*
> +* Case 2: node's successor is its right child
> + /* Case 3: node's successor is leftmost under its
> +* right child subtree
Hmm?
On Thu, 2012-08-02 at 15:34 -0700, Michel Lespinasse wrote:
+ /*
+* Case 2: node's successor is its right child
+ /* Case 3: node's successor is leftmost under its
+* right child subtree
Hmm?
--
To
On Mon, Aug 6, 2012 at 7:21 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2012-08-02 at 15:34 -0700, Michel Lespinasse wrote:
+ /* Case 3: node's successor is leftmost under its
+* right child subtree
Hmm?
Would 'leftmost under node's
On Mon, 2012-08-06 at 13:50 -0700, Michel Lespinasse wrote:
On Mon, Aug 6, 2012 at 7:21 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2012-08-02 at 15:34 -0700, Michel Lespinasse wrote:
+ /* Case 3: node's successor is leftmost under its
+
On Mon, Aug 6, 2012 at 1:58 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2012-08-06 at 13:50 -0700, Michel Lespinasse wrote:
On Mon, Aug 6, 2012 at 7:21 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2012-08-02 at 15:34 -0700, Michel Lespinasse wrote:
+
Various minor optimizations in rb_erase():
- Avoid multiple loading of node-__rb_parent_color when computing parent
and color information (possibly not in close sequence, as there might
be further branches in the algorithm)
- In the 1-child subcase of case 1, copy the __rb_parent_color field
On 08/02/2012 06:34 PM, Michel Lespinasse wrote:
Various minor optimizations in rb_erase():
- Avoid multiple loading of node->__rb_parent_color when computing parent
and color information (possibly not in close sequence, as there might
be further branches in the algorithm)
- In the 1-child
On 08/02/2012 06:34 PM, Michel Lespinasse wrote:
Various minor optimizations in rb_erase():
- Avoid multiple loading of node-__rb_parent_color when computing parent
and color information (possibly not in close sequence, as there might
be further branches in the algorithm)
- In the 1-child
Various minor optimizations in rb_erase():
- Avoid multiple loading of node->__rb_parent_color when computing parent
and color information (possibly not in close sequence, as there might
be further branches in the algorithm)
- In the 1-child subcase of case 1, copy the __rb_parent_color field
Various minor optimizations in rb_erase():
- Avoid multiple loading of node-__rb_parent_color when computing parent
and color information (possibly not in close sequence, as there might
be further branches in the algorithm)
- In the 1-child subcase of case 1, copy the __rb_parent_color field
14 matches
Mail list logo