Yeah, that's a fair point. In practice, too, I don't see us going above
three (maybe five?) of these stickies. Certainly not enough that going
through all the elements in the array would be a huge deal, especially
since we sometimes need random access, and sometimes need things in order.

Maybe if we had to go through the elements on the array multiple times on
the page...

well in either case, this looks good enough to go through. on the very
unlikely chance that this turns out to be too slow for what we need, we can
revisit.

On Fri, Mar 15, 2013 at 5:23 AM, annariel <notifications@github.com> wrote:

> In cgi-bin/LJ/User.pm:
>
> > @@ -2614,6 +2618,43 @@ sub invalidate_directory_record {
> >               undef, $u->id);
> >  }
> >
> > +# checks whether an entry id corresponds to that of a sticky entry which is under user's max_sticky_count.
> > +sub is_sticky_entry {
> > +    my ( $u, $ditemid ) = @_;
> > +
> > +    my @stickies = $u->sticky_entry;
> > +
> > +    for ( my $i = 1; $i<=$u->count_max_stickies; $i++ ) {
> > +        return 1 if ( $ditemid == $stickies[$i-1] );
>
> If we return a hash from sticky_entry then we'll need to also store the
> position in the list since stickies are ordered - I guess either the list
> position is the key and the ditemid the value or vice versa - we probably
> would want to use ditemid as the key in order to enable this quick lookup,
> but then we would, I think, need to reverse the hash every time the order
> of the elements was actually important (to let us lookup by list position,
> or iterate over the stickies in order).
>
> As you say a fair bit of work in sticky_entries as well - the key will be
> reading the comma separated string from the user prop into a two hashes
> (for used and unused stickies) in an efficient fashion. I'm guessing a map
> with a split would work, though I'm not sure what the efficiency
> implications would be - presumably the moment we use map over an array to
> get into a hash we've lost any gain we might have had by having the data
> stored as a hash. Though I could be wrong about that since I must have
> thought it was worth doing with the map over @input<https://github.com/input>in sticky_entry.
>
> Broadly speaking I'm don't know enough about the efficiency of various
> perl operators (reverse, map, split) to know if this would actually yield a
> gain in efficiency. If you think its worth doing I can give it a go.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/dreamwidth/dw-free/pull/276/files#r3382039>
> .
>