Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastImageCache – iOS library for quickly displaying images while scrolling

github.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#21

Post by cclogg »

mallorypaine wrote: post #16
alayne wrote: post #15

It's not using ARC. Is this legacy code, or couldn't they get equivalent performance with ARC enabled?

Hello. Mallory Paine here. I wrote FIC. This is not legacy code...it should be trivial to convert it to ARC and performance should be unaffected. I'm a bit old school myself so I chose to write it with manual retains. Does this approach make the code more difficult for you to use within an ARC project?

Actually you have my support for going manual. I still prefer to do all my projects without ARC (and I'm not old-school, unless 2009 is old-school). I just feel dirty everytime I use ARC, like I'm being sloppy haha. It also hides a lot about memory management that new people might never learn (and thus be in bigger trouble when something does go wrong). But I accept that it does have major advantages...

One trouble now is you never know if a library or whatnot will be ARC so it fragments things somewhat.

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#22

Post by alayne »

mallorypaine wrote: post #16
alayne wrote: post #15

It's not using ARC. Is this legacy code, or couldn't they get equivalent performance with ARC enabled?

Hello. Mallory Paine here. I wrote FIC. This is not legacy code...it should be trivial to convert it to ARC and performance should be unaffected. I'm a bit old school myself so I chose to write it with manual retains. Does this approach make the code more difficult for you to use within an ARC project?

It wouldn't be our only non-ARC framework. It might be interesting to benchmark an ARC version though.

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#23

Post by hboon »

rbritton wrote: post #20
allsystemsgo wrote: post #18

Earlier quoted context omitted.

Why would you write it with manual retains? Who doesn't use ARC at this point?

If the rest of the project is non-ARC it's easier in my experience to write new additions that way as well. I've only been using ARC on newly-created projects because having to add -fobjc-arc or -fno-objc-arc to dozens of files in Xcode is very, very tedious.

You can do a search to filter files in Xcode as well as cmd-click to select multiple files, the double click and enter the flags once for all of them.

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#24

Post by Groxx »

mallorypaine wrote: post #19
Groxx wrote: post #5

Earlier quoted context omitted.

Does mmapping the file mean that it'll block on file I/O if it's not already cached, though? I don't see any claims (haven't read the code) that it prevents this.

When the pages are first accessed, the file data is paged in, and yes, this will be a blocking operation. One way to mitigate this would be to force the data to be paged in using a background thread, so that the pages are live by the time Core Animation needs those bytes to render the layer. This page preheating isn't usually necessary for small images, which is the primary use case for FIC. FIC really pays off in a…

Aaah, all the text rendering, that lends more weight to storing them uncompressed. Hadn't thought of that, I was pondering more on the I/O being way slower than (uncontested, in retrospect) CPU of basic decompression.

Well, Path is amazingly smooth for how much styled stuff is in it, so nice work :) The UI really does stand out in how well it's done.

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#25

Post by aaronbrethorst »

alayne wrote: post #15

It's not using ARC. Is this legacy code, or couldn't they get equivalent performance with ARC enabled?

meh. It's a bit odd, and I don't understand why someone would choose to manually manage memory, but

    -fobj-arc
and

    -fno-objc-arc
are handy ways to manage ARC and non-ARC files in your projects, depending on what your yen for -retain and -release are.

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#26

Post by nielsbot »

mallorypaine wrote: post #16
alayne wrote: post #15

It's not using ARC. Is this legacy code, or couldn't they get equivalent performance with ARC enabled?

Hello. Mallory Paine here. I wrote FIC. This is not legacy code...it should be trivial to convert it to ARC and performance should be unaffected. I'm a bit old school myself so I chose to write it with manual retains. Does this approach make the code more difficult for you to use within an ARC project?

It might even be faster under ARC since I think the compiler can optimize some retain/release calls. I think the ARC retain and release may be faster than -retain/-release, but I'm not sure about that.

Overall, yes, it's less smooth to include non-ARC code in an ARC project.

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#27

Post by nielsbot »

cclogg wrote: post #21
mallorypaine wrote: post #16

Earlier quoted context omitted.

Hello. Mallory Paine here. I wrote FIC. This is not legacy code...it should be trivial to convert it to ARC and performance should be unaffected. I'm a bit old school myself so I chose to write it with manual retains. Does this approach make the code more difficult for you to use within an ARC project?

Actually you have my support for going manual. I still prefer to do all my projects without ARC (and I'm not old-school, unless 2009 is old-school). I just feel dirty everytime I use ARC, like I'm being sloppy haha. It also hides a lot about memory management that new people might never learn (and thus be in bigger trouble when something does go wrong). But I accept that it does have major advantages... One trouble n…

If you know how to use retain/release, then you shouldn't have any trouble dealing with ARC edge cases... go ARC!

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#28

Post by nielsbot »

rbritton wrote: post #14

As they made some note of, Core Animation is very picky about the image format you provide via the contents property. For example, if you retain a reference to a CGImageRef that you also assign to a CALayer's contents property, you will end up with at least double the memory usage if it's not in CA's preferred format and it makes a copy of it. In my experience doing that alone can help performance immensely. I've sin…

I think it can change from device to device too

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#29

Post by nielsbot »

skyebook wrote: post #6
liuliu wrote: post #2

It does seem weird that they store the uncompressed image on the disk. I think that a benchmark on this comparing with compressed / decompress on CPU would be interesting because one is bounded on I/O, another is bounded by CPU throughput.

It actually isn't all that surprising, we've hit similar bottlenecks where JPEG decompression on the iPhone ends up choking feeds that are scrolled through quickly. We didn't go the route of caching the uncompressed data on disk, though, we just keep the images in a maintained in-memory cache.

that can work depending on how many images you have... Note also that there's a decompression hit loading PNG too.

Re: FastImageCache – iOS library for quickly displaying images while scrolling

#30

Post by nielsbot »

mallorypaine wrote: post #19
Groxx wrote: post #5

Earlier quoted context omitted.

Does mmapping the file mean that it'll block on file I/O if it's not already cached, though? I don't see any claims (haven't read the code) that it prevents this.

When the pages are first accessed, the file data is paged in, and yes, this will be a blocking operation. One way to mitigate this would be to force the data to be paged in using a background thread, so that the pages are live by the time Core Animation needs those bytes to render the layer. This page preheating isn't usually necessary for small images, which is the primary use case for FIC. FIC really pays off in a…

I've used this to track down my scrolling performance problems in the past, although it's been a while: https://github.com/nielsbot/Profiler (yes, I'm plugging my own code :-)
Post reply on HN