heavy performance issue

[gbrbks]

Hello guys!

I experienced a strange behavior if I try to load a couple 480x320 jpg file into a 100dp x 100dp imageviews (5-6 max on the screen in portrait mode) in a gridview, it is lagging heavily except if it comes from the cache itself. However when i'm trying to load much smaller pictures it is totally smooth. I'm 99% sure that is related to the cache because if i'm using the .skipMemoryCache() function it is much more better! This is happening on all device not just on my n5.

The library usage is not overly complicated.
Picasso.with(mContext).load(mModel.getImageLink()).into(mPreviewImage);

There are 4 more textviews next to the image in the cell. If'm not loading any images then it is totally okay. The overdraws are minimized everything is green and blue. The latest okhttp 1.5.4 is present. There could be 2000 elements in the adapter. I'm using your awesome library from the beginning and never experienced such a performance drop.

sample urls:
big
http://d1bko2jzh7ix12.cloudfront.net/5/c6c469346129c00b9c69b63d092a6f68/gm.jpg
small
http://d1bko2jzh7ix12.cloudfront.net/5/c6c469346129c00b9c69b63d092a6f68/t.jpg

Thanks in advance!

Cheers,
Gabor

[cgollner]

You should always resize your images to the size of the target:

int dp100 = ... 
Picasso.with(mContext).load(mModel.getImageLink()).resize(dp100,dp100).into(mPreviewImage);

[gbrbks]

Unfortunately it works the same :( and blocking the UI thread

[gbrbks]

I forget to mentioned that it is happening mainly when i'm scrolling very fast.

[gbrbks]

I thought the same as well first and I double checked it (again) and everything has a precise height.

[gbrbks]

Maybe a traceview screenshot could help a little bit.
https://www.dropbox.com/s/ayxx2l535w9b8bv/Screen%20Shot%202014-05-18%20at%2014.43.14.png

this is the first 5 element order by EXCL CPU TIME

[dnkoutso]

Thanks for the report. This is actually the decode of the bitmap that takes too long. Can you please provide a sample app for me so I can further investigate?

[gbrbks]

Thanks for the reply. Sadly i'm not allowed to send it, but i'll look after the possibilities. I'll get back go you soon. The other pictures are the same as I posted before.

[dnkoutso]

There is a possibility that too many bitmaps load too quickly. I saw your URL is rather a small image.

We're also using a batch delay for picasso so thats also a bit surprising. Have you tried using a single thread executor? Just to ensure that this could be it?

[gbrbks]

I tried to create my Picasso instance with the following piece of code.
picasso = new Picasso.Builder(context).executor(Executors.newSingleThreadExecutor()).build();
Still the same.

[dnkoutso]

I'll need to recreate a similar app to test it out.

How does the sample app work for you in terms of speed?

[gbrbks]

The screen that contains the problematic part has just a gridview with relative layout above. The information comes from an API which parsed by jackson json parser. The cells has 4 textviews and 3 images (2 are fixed icons) including the loaded part. If I comment out the image loading it is as smooth as possible without any hiccup.

[dnkoutso]

For reference, we will have a ScrollListener mode in Picasso in version 2.4. This would allow you to scroll and not load images until scrolling has finished.

I know you obviously dont want to wait so I will be looking to see what I can do between that.

2.3 should be out next week and includes a few performance improvements.. I doubt collectively they would help in the overall experience you have.

[gbrbks]

Whoa! That will be an awesome feature. If i found any other clue i'll post it here immediately.

[dnkoutso]

I think its just too many bitmaps loading quickly. Most of them are from disk so they are reloaded very very fast.

Do you have debug indicators enabled? Those would also slow down rendering.

Feel free to submit a PR for performance improvements.