On Wed, Sep 11, 2013 at 4:11 PM, <[email protected]> wrote: > On 2013/09/11 13:53:45, titzer wrote: > >> On 2013/09/11 10:34:07, rossberg wrote: >> > https://codereview.chromium.**org/23609020/diff/1/src/**hydrogen.h<https://codereview.chromium.org/23609020/diff/1/src/hydrogen.h> >> > File src/hydrogen.h (right): >> > >> > https://codereview.chromium.**org/23609020/diff/1/src/** >> hydrogen.h#newcode2309<https://codereview.chromium.org/23609020/diff/1/src/hydrogen.h#newcode2309> >> > src/hydrogen.h:2309: class HUnique V8_FINAL { >> > I think this should live somewhere else (e.g. handles.h or perhaps its >> own >> > file), and be named Unique, since it isn't really specific to Hydrogen. >> > > Yeah I agree that we might want it to live in a more general place later, >> but >> > I > >> don't want to go too far down the path of generalizing it just yet. So, I >> want >> to introduce it and start using in hydrogen, and when we find other uses >> for >> > it, > >> we can move it out. >> > > It's already perfectly general. That's why this is the wrong place to put > it. ;) > And hydrogen.h is far too long already anyway.
Premature abstraction, I say! > > > > Oh alright. You fancy kids and your && constructs. >> > > I'd like to propose a 5€ kitty tax for unjustified uses of goto (a.k.a. > break). > :) > > A break is not a goto. You can't create irreducible flow graphs with break. > > > > https://codereview.chromium.**org/23609020/diff/1/src/** >> hydrogen.h#newcode2518<https://codereview.chromium.org/23609020/diff/1/src/hydrogen.h#newcode2518> >> > src/hydrogen.h:2518: int new_capacity = capacity_ + capacity_ + size; >> // >> > 2*current + needed >> > That seems like a lot, and can cause up to a 200% space overhead. >> What's the >> > rationale? >> > > I've used this growth heuristic before and it works pretty nicely. The >> > rationale > >> is that most sets will be 1 element, probably 99.9% after that will be <= >> 4 >> elements (in fact, SmallMapList is limited to 4 elements, IIRC). Other >> sets >> might be big, so you want to grow aggressively to avoid copying. >> > > Note that on average, you copy half of the array anyway. If minimizing > copying > was a concern, it might be worth avoiding the duplicate copying. But I > agree > that for the sizes we are dealing with here, it probably doesn't matter > either > way. > > https://codereview.chromium.**org/23609020/<https://codereview.chromium.org/23609020/> > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
