Logging statements (like the ones in the LruBitmapPool) make the app drop frames about glide

[sjudd]

It's probably as much String.format as locking around Log, but it's still unfortunate. We use proguard to strip out Log.v and Log.d in our release builds of our apps, partly to solve this kind of problem:

-assumenosideeffects class android.util.Log {
    public static int v(...);
}
-assumenosideeffects class android.util.Log {
    public static int d(...);
}
-assumenosideeffects class android.util.Log {
    public static int i(...);
}

If this is causing enough frames to drop that its super noticeable while developing, it may be best to do what you're suggesting and only turn on logging if explicitly requested. I'd assumed that the frame drop from all of the garbage collections caused by the first bit of scrolling (when we don't have any bitmaps to recycle) would overwhelm any side affects of logging, but maybe that's not a valid assumption.

I'll look in to adding some debug method to Glide to enable/disable logging.

[csobrinho]

I noticed that after the images were on cache that the scrolling was very fast, even on a custom complicated layout.
But, from time to time the scrolling was really slow and sometimes it got almost 1s stop.

Setting DEBUG to false fixed and it makes some sense because we have a lot of small images and we could get between 10-20 logging images while flinging one full page of the ListView.

Thanks for the quick support!

[sjudd]

I couldn't think of a nicer way to implement this, so I used what you suggested: c29ca39

In the future I could see wanting to enable or disable some other types of debugging but this seems like a logical first step. Thanks for reporting the issue and providing a solution.