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 mikey-...@bungie.org wrote: On 9 Apr, 2014, at 0:52, Maxthon Chan xcvi...@me.com 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
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 fri...@manoverboard.org 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 mikey-...@bungie.org wrote: On 9 Apr, 2014, at 0:52, Maxthon Chan xcvi...@me.com 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
when all you have is a rocket launcher, every problem looks like rocket bait. -- On 9 Apr, 2014, at 0:52, Maxthon Chan xcvi...@me.com 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 cocoa...@charlessoft.com wrote: On Apr 9, 2014, at 2:20 AM, Maxthon Chan xcvi...@me.com 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 9, 2014, at 12:32 AM, John Joyce dangerwillrobinsondan...@gmail.com 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
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 cocoa...@charlessoft.com wrote: On Apr 9, 2014, at 12:32 AM, John Joyce dangerwillrobinsondan...@gmail.com 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 2:20 AM, Maxthon Chan xcvi...@me.com 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
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 cocoa...@charlessoft.com wrote: On Apr 9, 2014, at 2:20 AM, Maxthon Chan xcvi...@me.com 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 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
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 witness.of.teacht...@gmx.net 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 Apr 8, 2014, at 10:32 PM, John Joyce dangerwillrobinsondan...@gmail.com 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
On Apr 8, 2014, at 12:13 PM, Michael Domino michael.dom...@identityfinder.com 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
Re: Excessive open gui graphics files on Mavericks
On Apr 8, 2014, at 16:15 , Jens Alfke j...@mooseyard.com 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 michael.dom...@identityfinder.com 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
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 gpar...@apple.com wrote: On Apr 8, 2014, at 12:13 PM, Michael Domino michael.dom...@identityfinder.com 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 8:57 PM, Maxthon Chan xcvi...@me.com 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
On 2014/04/09, at 13:28, Jens Alfke j...@mooseyard.com wrote: On Apr 8, 2014, at 8:57 PM, Maxthon Chan xcvi...@me.com 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
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 j...@mooseyard.com wrote: On Apr 8, 2014, at 8:57 PM, Maxthon Chan xcvi...@me.com 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 9, 2014, at 2:28 PM, ChanMaxthon xcvi...@me.com 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
