Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

dearvivekkumar

macrumors newbie
Original poster
Jan 3, 2011
9
0
New Delhi, India
Hi,
Code:
    // On each iteration of the do-while loop, retrieve this
    // number of catalog infos
    //
    // We use the number of FSCatalogInfos that will fit in
    // exactly four VM pages (#113). This is a good balance
    // between the iteration I/O overhead and the risk of
    // incurring additional I/O from additional memory
    // allocation
    [B][COLOR="Red"]const size_t kRequestCountPerIteration = ((4096 * 4) / sizeof(FSCatalogInfo));[/COLOR][/B]

i have taken this code from the mac documentation "iterating directory in carbon"

I am not getting what the line above is actually doing? So its is so?

Please explain.

Thanks
 
It's kind of just like what the comments say.

A memory page is 4KB (or 4096) bytes. The expression starts off by calculating the size of 4 memory pages (4 * 4KB or 4 * 4096 = 16,384).

It then goes on to calculate how many FSCatalogInfos will find into 4 memory pages by dividing 4 * 4096 by the size of a single FSCatalogInfo.

It turns of an FSCatalogInfo is 144 bytes when compiling 32bit i386 code. kRequestCountPerIteration is therefore 113, meaning one can store 113 FSCatalogInfos in 4 memory pages, and every iteration will retrieve 113 FSCatalogInfos.
 
Thanks for your reply.

please explain why 4kb of memory page is used here, any specific reason?

Because later in this code if i wants to collects all the FSRef using FSGetCatalogInfoBulk() this then i have created a array of FSRef and for the size of this array i have used kRequestCountPerIteration.

Because while i was implementing this function, i dont know what i have to put so o tested with it, now its running smoothly but its always strike me y this..??

please explain if possible.
 
please explain why 4kb of memory page is used here, any specific reason?

It's something defined by the combination of operating system and CPU. Mac OS X on Intel CPUs (and PowerPC's as well? I don't know) has the virtual memory divided into memory pages of 4KB each.

BTW If you are only getting FSRefs from FSGetCatalogInfoBulk (ie passing NULL as catalogInfos), then passing kRequestCountPerIteration as maximumObjects to FSGetCatalogInfoBulk is rather irrelevant / arbitrary. This is because kRequestCountPerIteration has calculated a good performance / through-put size for retrieving FSCatalogInfos in bulk. You will however get away with it. Just as long as your FSRefs array passed into the refs parameter is kRequestCountPerIterations long.
 
Last edited:
please explain why 4kb of memory page is used here, any specific reason?

http://en.wikipedia.org/wiki/Protected_mode#Paging

The '386 processor defines a page of memory as 4 KB, so reads of this size translate to efficient assembly code.

As jiminaus says you get 113 FSCatalogInfo entries when you read 4 pages of memory, so it would not make sense to read 28.25 at a time (one page), best to pick them up in block of 113 at a time (four pages).

B
 
so what value is good for this situation

I don't know. I don't have any experience with Carbon.

An FSRef is 80 bytes. In theory, you can get 204 (that's 4 * 4096 / 80) of them into 4 memory pages. You can try to read that many in one go and see what your performance is like.

But really you'd need to play with the number while running under a profiler so see how FSGetCatalogInfoBulk performs with different numbers when getting FSRefs. It's an I/O bound operation, so you should see the through-put increase until the number hits a ceiling. After that either the through-put will either plateau or start decreasing.
 
On my system its coming ut to be 113. Earlier i thought that its has any specific meaning with this number.

Thanks u all for ur great explanation!! thanks alot.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.