Re: Excessive open gui graphics files on Mavericks
The game never saw the light of day actually, and we was on the way reimplementing libcramfs in BSD license. On Apr 11, 2014, at 22:56, Fritz Anderson wrote: > (The attribution chain is wrong, because I’m coming to this after the message > that raised libcramfs.) > > It’s remarkably hard to get an answer to this, so I may be talking through my > hat: > > Does this involve linking libcramfs.a into the binary you distribute? Have > you published the source of your app? > > — F > > > On 10 Apr 2014, at 2:16 AM, Michael Watson wrote: > >> On 9 Apr, 2014, at 0:52, Maxthon Chan wrote: >> >>> LOL >>> >>> I actually used cramfs once in a game carried the rules database. The rules >>> are so complicated so I tried to make it smaller without sacrificing the >>> efficiency of the game code. Ended up using cramfs for that. >>> > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com > > This email sent to xcvi...@me.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
(The attribution chain is wrong, because I’m coming to this after the message that raised libcramfs.) It’s remarkably hard to get an answer to this, so I may be talking through my hat: Does this involve linking libcramfs.a into the binary you distribute? Have you published the source of your app? — F On 10 Apr 2014, at 2:16 AM, Michael Watson wrote: > On 9 Apr, 2014, at 0:52, Maxthon Chan wrote: > >> LOL >> >> I actually used cramfs once in a game carried the rules database. The rules >> are so complicated so I tried to make it smaller without sacrificing the >> efficiency of the game code. Ended up using cramfs for that. >> ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
when all you have is a rocket launcher, every problem looks like rocket bait. -- On 9 Apr, 2014, at 0:52, Maxthon Chan wrote: > LOL > > I actually used cramfs once in a game carried the rules database. The rules > are so complicated so I tried to make it smaller without sacrificing the > efficiency of the game code. Ended up using cramfs for that. > > On Apr 9, 2014, at 15:49, Charles Srstka wrote: > >> On Apr 9, 2014, at 2:20 AM, Maxthon Chan wrote: >> >>> I’d recommend cramfs as it is a real filesystem that is optimised to be >>> expanded in-memory. >> >> Not complicated enough. I'd recommend encrypting the whole thing with an >> AES-256 key which is encrypted using elliptical-curve cryptography, and >> stuff it into a disk image (NDIF, ADC compression) and compress that using >> zlib, LZMA, and the old PKZIP Implode algorithm. Then, encode the resulting >> bytes by finding the first offset at which each digit occurs in the decimal >> representation of pi, then encode the octal representation of those numbers >> in EBCDIC format, then compress it again and encode the resulting bytes as >> offsets into an Ogg Vorbis recording of the soundtrack to Star Trek V: The >> Final Frontier. >> >> Because why the hell not? >> >> Charles >> > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/mikey-san%40bungie.org > > This email sent to mikey-...@bungie.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On Apr 8, 2014, at 10:32 PM, John Joyce wrote: > Base64 would work in plists / xml / keyed archives / yaml / json whatever. > Serializing a dictionary or custom object would make it really simple and > easy to manage. > As a text file, you could compress the heck out of it if needed to reduce > file size for app distribution. > Decompress it at first launch into the app’s Application Support folder. I’m scratching my head trying to figure out whether this is satire or not (some of the replies obviously are.) Actually I kind of suspect this is the exact packaging used for Adobe apps: it would explain their immense size and lengthy installation procedures. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
cramps features decompression in-memory in place and to avoid copying data you can put uncompressed TIFF in it. cramfs decompresses into NSData objects in-place and can be taken up directly by NSImage/UIImage/CGImage/CIImage object. cramfs variant that is based on zlib makes that image a equivalent of PNG format. On Apr 9, 2014, at 17:29, Uli Kusterer wrote: > On 09 Apr 2014, at 07:22, dangerwillrobinsondan...@gmail.com wrote: >> Base64 encode images into one file. It could even be an SQLite db file. > > I’d recommend against base64-encoding possibly large binary data like image > files. base64 makes it balloon in size. It’s fine for storing small binary > bits like bookmark data (i.e. aliases) or NSDates in an Info.plist or XML > file, but if there are enough images to cause running out of file > descriptors, they are enough images that the overhead of base64-decoding will > be relevant. > > I worked on a project where we used to store a (comparatively small, ~700x500 > pixels) preview of a JPEG file in a plist file as NSData. Even then we > realized that decoding of this data was a big bottleneck for load times when > showing a list of all these previews. We eventually switched to a separate > image file and had a large benefit. Later when the previews needed to become > larger, this saved our bacon. Given most common image formats these days are > compressed already, anything beyond a tarball probably hurts more than it > helps. > > Now admittedly, we also gained the ability to not have to load the image file > just because we needed some other key from the plist, but just moving the > data from a hard disk over the bus can be a bottleneck, not even mentioning > having to process each byte (and thus copying it again). Especially since > that’s just to get the raw JPEG data, which is then decompressed and thus > “copied” again. > > Cheers, > -- Uli Kusterer > “The Witnesses of TeachText are everywhere...” > http://zathras.de > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com > > This email sent to xcvi...@me.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On 09 Apr 2014, at 07:22, dangerwillrobinsondan...@gmail.com wrote: > Base64 encode images into one file. It could even be an SQLite db file. I’d recommend against base64-encoding possibly large binary data like image files. base64 makes it balloon in size. It’s fine for storing small binary bits like bookmark data (i.e. aliases) or NSDates in an Info.plist or XML file, but if there are enough images to cause running out of file descriptors, they are enough images that the overhead of base64-decoding will be relevant. I worked on a project where we used to store a (comparatively small, ~700x500 pixels) preview of a JPEG file in a plist file as NSData. Even then we realized that decoding of this data was a big bottleneck for load times when showing a list of all these previews. We eventually switched to a separate image file and had a large benefit. Later when the previews needed to become larger, this saved our bacon. Given most common image formats these days are compressed already, anything beyond a tarball probably hurts more than it helps. Now admittedly, we also gained the ability to not have to load the image file just because we needed some other key from the plist, but just moving the data from a hard disk over the bus can be a bottleneck, not even mentioning having to process each byte (and thus copying it again). Especially since that’s just to get the raw JPEG data, which is then decompressed and thus “copied” again. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
LOL I actually used cramfs once in a game carried the rules database. The rules are so complicated so I tried to make it smaller without sacrificing the efficiency of the game code. Ended up using cramfs for that. On Apr 9, 2014, at 15:49, Charles Srstka wrote: > On Apr 9, 2014, at 2:20 AM, Maxthon Chan wrote: > >> I’d recommend cramfs as it is a real filesystem that is optimised to be >> expanded in-memory. > > Not complicated enough. I'd recommend encrypting the whole thing with an > AES-256 key which is encrypted using elliptical-curve cryptography, and stuff > it into a disk image (NDIF, ADC compression) and compress that using zlib, > LZMA, and the old PKZIP Implode algorithm. Then, encode the resulting bytes > by finding the first offset at which each digit occurs in the decimal > representation of pi, then encode the octal representation of those numbers > in EBCDIC format, then compress it again and encode the resulting bytes as > offsets into an Ogg Vorbis recording of the soundtrack to Star Trek V: The > Final Frontier. > > Because why the hell not? > > Charles > signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On Apr 9, 2014, at 2:20 AM, Maxthon Chan wrote: > I’d recommend cramfs as it is a real filesystem that is optimised to be > expanded in-memory. Not complicated enough. I'd recommend encrypting the whole thing with an AES-256 key which is encrypted using elliptical-curve cryptography, and stuff it into a disk image (NDIF, ADC compression) and compress that using zlib, LZMA, and the old PKZIP Implode algorithm. Then, encode the resulting bytes by finding the first offset at which each digit occurs in the decimal representation of pi, then encode the octal representation of those numbers in EBCDIC format, then compress it again and encode the resulting bytes as offsets into an Ogg Vorbis recording of the soundtrack to Star Trek V: The Final Frontier. Because why the hell not? Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
I’d recommend cramfs as it is a real filesystem that is optimised to be expanded in-memory. On Apr 9, 2014, at 14:42, Charles Srstka wrote: > On Apr 9, 2014, at 12:32 AM, John Joyce > wrote: > >> Sure. Core Data would work just as well as binary blobs. >> Base64 would work in plists / xml / keyed archives / yaml / json whatever. >> Serializing a dictionary or custom object would make it really simple and >> easy to manage. > > This is true. Also: just reading the individual files with NSData would work > just as well as any of those. > >> As a text file, you could compress the heck out of it if needed to reduce >> file size for app distribution. > > Which would surely make a world of difference, given that these are *image > files* and thus probably already compressed. > > Charles > signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On Apr 9, 2014, at 12:32 AM, John Joyce wrote: > Sure. Core Data would work just as well as binary blobs. > Base64 would work in plists / xml / keyed archives / yaml / json whatever. > Serializing a dictionary or custom object would make it really simple and > easy to manage. This is true. Also: just reading the individual files with NSData would work just as well as any of those. > As a text file, you could compress the heck out of it if needed to reduce > file size for app distribution. Which would surely make a world of difference, given that these are *image files* and thus probably already compressed. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On Apr 9, 2014, at 2:28 PM, ChanMaxthon wrote: > The SQLite DB thing is just like a tar archive, and if you dare to you can > even include a cramfs driver in your code and consolidate all your resources > into one optionally encrypted cramfs image. Every file archiving method that > allows in-memory expansion works, and my personal recommendation is tar and > cramfs, since the first is very common and easily handled, and the latter is > a proper file system that is designed to be expanded in memory (mostly used > as initramfs for Linux) > > Sent from my iPad Sure. Core Data would work just as well as binary blobs. Base64 would work in plists / xml / keyed archives / yaml / json whatever. Serializing a dictionary or custom object would make it really simple and easy to manage. As a text file, you could compress the heck out of it if needed to reduce file size for app distribution. Decompress it at first launch into the app’s Application Support folder. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
The SQLite DB thing is just like a tar archive, and if you dare to you can even include a cramfs driver in your code and consolidate all your resources into one optionally encrypted cramfs image. Every file archiving method that allows in-memory expansion works, and my personal recommendation is tar and cramfs, since the first is very common and easily handled, and the latter is a proper file system that is designed to be expanded in memory (mostly used as initramfs for Linux) Sent from my iPad > On Apr 9, 2014, at 1:22 PM, dangerwillrobinsondan...@gmail.com wrote: > > > >> On 2014/04/09, at 13:28, Jens Alfke wrote: >> >> >>> On Apr 8, 2014, at 8:57 PM, Maxthon Chan wrote: >>> >>> You can avoidd this by consolidating all your resource files into one big >>> archive file that is expanded in-memory into NSData files. I still vaguely >>> remember a library that parses tar file into a dictionary of NSData >>> objects. You can use that library to consolidate all your resources into >>> one single tarball. >> >> I don’t think that has anything to do with this. If you want to avoid >> +imageNamed:, it’s easy to load individual image files as data, as I said, >> without having to change anything about the way the resources are stored on >> disk. >> >> —jens > > It might be good to know if any of the file descriptors are pointing to the > same files. > From the lsof snippet the files are in your bundle so look at how your code > is loading resources. If you have duplicate descriptors you want to find a > way to load lazily, load once and let go if the descriptor when not in use. > Here's one way. > If you have tons of images, borrow a page from Sprite Kit, use an image > atlas. One descriptor, many positional images. > It's just an image with subimages at known positions. Then you can reuse the > same image and just draw the parts you need where you need them. > > Other similar alternatives. > Base64 encode images into one file. It could even be an SQLite db file. > Fetch the encoded images you need and decode. > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
> On 2014/04/09, at 13:28, Jens Alfke wrote: > > >> On Apr 8, 2014, at 8:57 PM, Maxthon Chan wrote: >> >> You can avoidd this by consolidating all your resource files into one big >> archive file that is expanded in-memory into NSData files. I still vaguely >> remember a library that parses tar file into a dictionary of NSData objects. >> You can use that library to consolidate all your resources into one single >> tarball. > > I don’t think that has anything to do with this. If you want to avoid > +imageNamed:, it’s easy to load individual image files as data, as I said, > without having to change anything about the way the resources are stored on > disk. > > ―jens It might be good to know if any of the file descriptors are pointing to the same files. From the lsof snippet the files are in your bundle so look at how your code is loading resources. If you have duplicate descriptors you want to find a way to load lazily, load once and let go if the descriptor when not in use. Here's one way. If you have tons of images, borrow a page from Sprite Kit, use an image atlas. One descriptor, many positional images. It's just an image with subimages at known positions. Then you can reuse the same image and just draw the parts you need where you need them. Other similar alternatives. Base64 encode images into one file. It could even be an SQLite db file. Fetch the encoded images you need and decode. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On Apr 8, 2014, at 8:57 PM, Maxthon Chan wrote: > You can avoidd this by consolidating all your resource files into one big > archive file that is expanded in-memory into NSData files. I still vaguely > remember a library that parses tar file into a dictionary of NSData objects. > You can use that library to consolidate all your resources into one single > tarball. I don’t think that has anything to do with this. If you want to avoid +imageNamed:, it’s easy to load individual image files as data, as I said, without having to change anything about the way the resources are stored on disk. —jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
You can avoidd this by consolidating all your resource files into one big archive file that is expanded in-memory into NSData files. I still vaguely remember a library that parses tar file into a dictionary of NSData objects. You can use that library to consolidate all your resources into one single tarball. On Apr 9, 2014, at 11:26, Greg Parker wrote: > On Apr 8, 2014, at 12:13 PM, Michael Domino > wrote: >> Some of my customers running on Mavericks are having problems with "too many >> open files" errors. Raising the limit does solve the problem, but I've >> noticed that on 10.6, at idle, my app opens about 47 files, none of them gui >> graphics files. On Mavericks, the very same build of the app opens 102 files >> and keeps them open for the duration of the process existence. > > Dumb solution: raise the open file limit. > > The default limit for an application double-clicked in the Finder is 256 > descriptors. You can raise it by calling setrlimit() with the RLIMIT_NOFILE > option. Setting it to something like 512 or 1024 during your app's launch > should help your customers out while you figure out if there is excessive > descriptor use in your app or in the OS. > > If your customers start hitting the higher limit then you know you have a > more serious problem to resolve. There is a system-wide limit (around 20K > IIRC) so you can't just raise it forever. > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com > > This email sent to xcvi...@me.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On Apr 8, 2014, at 12:13 PM, Michael Domino wrote: > Some of my customers running on Mavericks are having problems with "too many > open files" errors. Raising the limit does solve the problem, but I've > noticed that on 10.6, at idle, my app opens about 47 files, none of them gui > graphics files. On Mavericks, the very same build of the app opens 102 files > and keeps them open for the duration of the process existence. Dumb solution: raise the open file limit. The default limit for an application double-clicked in the Finder is 256 descriptors. You can raise it by calling setrlimit() with the RLIMIT_NOFILE option. Setting it to something like 512 or 1024 during your app's launch should help your customers out while you figure out if there is excessive descriptor use in your app or in the OS. If your customers start hitting the higher limit then you know you have a more serious problem to resolve. There is a system-wide limit (around 20K IIRC) so you can't just raise it forever. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On Apr 8, 2014, at 16:15 , Jens Alfke wrote: > IIRC, the AppKit release notes for 10.9 (or 10.8?) talk about behavior > changes in +[NSImage imageNamed:]. Putting that together with what you’re > saying, it may be that it now memory-maps the image data instead of copying > it into heap space. That would be more memory efficient but has the side > effect of consuming a file descriptor. What the release notes for 10.9 actually say is: > "Prior to Mac OS 10.9 images loaded through +[NSImage imageNamed:] were > retained for the lifetime of the application. For applications linked on 10.9 > and later this is no longer the case. Images loaded through +[NSImage > imageNamed:] will still be cached for a brief time.” which suggests less caching, not more, though file descriptor usage could still be implicated. The other thing is, in the past when I inadvertently used up all the file descriptors, the limit was about 8000 descriptors. If we’re talking about even a couple of hundred descriptors here, it seems likely that whatever’s using descriptors indiscriminately is elsewhere in the app. (Though of course avoiding the waste of a couple of hundred is worth doing too.) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Excessive open gui graphics files on Mavericks
On Apr 8, 2014, at 12:13 PM, Michael Domino wrote: > The difference is the graphics files used by the gui. There are no .png files > opened on 10.6 while the app is at idle, but on Mavericks we have all of > these taking up file descriptors (partial lsof output below). IIRC, the AppKit release notes for 10.9 (or 10.8?) talk about behavior changes in +[NSImage imageNamed:]. Putting that together with what you’re saying, it may be that it now memory-maps the image data instead of copying it into heap space. That would be more memory efficient but has the side effect of consuming a file descriptor. > I don't directly open any of these files, and the only visible icons at the > time are the 15 main toolbar buttons. > So is there a way to change this behavior and close these files? I suspect you didn’t directly open the files, but called +[NSImage imageNamed:] and retained the NSImage object, which is now hanging onto a file descriptor. If this is true, you may be able to get around it by either keeping fewer of these resource-based NSImages around, at least not ones that aren’t currently being displayed, or by loading them using a different API. For example you could load the data into an NSData and then create an NSImage from that. Disclaimer: This is total speculation and quite possibly wrong. But it should at least give you some ideas for experiments or workarounds. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Excessive open gui graphics files on Mavericks
Hi all, Some of my customers running on Mavericks are having problems with "too many open files" errors. Raising the limit does solve the problem, but I've noticed that on 10.6, at idle, my app opens about 47 files, none of them gui graphics files. On Mavericks, the very same build of the app opens 102 files and keeps them open for the duration of the process existence. The difference is the graphics files used by the gui. There are no .png files opened on 10.6 while the app is at idle, but on Mavericks we have all of these taking up file descriptors (partial lsof output below). I don't directly open any of these files, and the only visible icons at the time are the 15 main toolbar buttons. So is there a way to change this behavior and close these files? This product is currently built using Xcode 3.2.6. Would upgrading to the latest Xcode have any effect? Thanks, Michael lsof output: COMMAND PIDUSER FD TYPE DEVICE SIZE/OFFNODE NAME Identity 275 michael txt REG1,1 546 2633476 /Applications/Identity Finder.app/Contents/Resources/status_ssn.png Identity 275 michael txt REG1,1 433 2633454 /Applications/Identity Finder.app/Contents/Resources/status_credit-card.png Identity 275 michael txt REG1,1 593 2633472 /Applications/Identity Finder.app/Contents/Resources/status_password.png Identity 275 michael txt REG1,1 577 2633450 /Applications/Identity Finder.app/Contents/Resources/status_bank-acct.png Identity 275 michael txt REG1,1 545 2633458 /Applications/Identity Finder.app/Contents/Resources/status_drivers-license.png Identity 275 michael txt REG1,1 537 2633452 /Applications/Identity Finder.app/Contents/Resources/status_birthdate.png ...and many more... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
