[Webkit-unassigned] [Bug 44806] Use purgeable memory to keep more dead resources in cache

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=44806


Pratik Solanki <psolanki at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |psolanki at apple.com




--- Comment #5 from Pratik Solanki <psolanki at apple.com>  2010-08-30 15:33:54 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > (From update of attachment 65814 [details] [details])

> > Do we really need the optimization for a resource with a size of zero? Is that a common case that needs to be faster than other cases? I would write:

> > By the way, if we did need it, I still think that scoping the local variable to the if would be nicer style.

I'm leaving the check for 0 in to be consistent. If we want to get rid of the check, let me know and I can clean up all the call sites in a follow on bug.

> > Is the static_cast here really needed? Why exactly?
> This part of the code was copied from evict(). It does the static_cast as well. resource->size() returns an unsigned int so maybe the cast was added for that reason?

Leaving the static_cast in as well since resource->size() returns unsigned.

> > > -    if (isSafeToMakePurgeable())
> > > -        makePurgeable(true);
> > > +    if (!Cache::markMemoryPurgeableOnEvict()) {
> > > +        if (isSafeToMakePurgeable())
> > > +            makePurgeable(true);
> > > +    }
> > 
> > I think && would be better here than nesting ifs, but also, can the check go lower level, inside isSafeToMakePurgeable and markPurgeable?
> 
> && is easy to do. I'll have to investigate if the check can go lower into makePurgeable(). 

It didn't look straightforward to move the check down to makePurgeable() so I'm leaving it where it is right now.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.