In an iOS app, I take a four digit code from the user and give them a corresponding string in a TextView. My question is, because there are about a thousand possible codes the user would enter that I am checking for, what is an efficient way to give a result without having a huge if or switch statement? Like, using a plist, txt file, or even database.... Thanks in advance
The decision of plist, text file or database is just a matter of storage, not search. Personally, I would just use a JSON file, since it's reasonably well-supported both by the human brain and by software. For searching, just put them in an NSDictionary and do a lookup on that. Unless your items are very big, 1000 items is not really a large dataset, even on a memory-constrained iPhone. Even if each item is 1 KB (which sounds a lot larger than the dataset you're describing), you're looking at less than a megabyte for the whole set.
If the strings happen to be long, then store the long text in a file and store the file URL in your lookup table instead of the whole string. IIRC, a URL is about 100 bytes on average, and an NSNumber is about 8, so you'd be looking at about 108 KB for the entire dataset.
Given the number of possible codes I would recommend Core Data. Alternatively you can use SQLite directly. You could use a plist, but I fear it would quickly become unmanageable as you add, remove, and update codes.
Related
I am writing a (linguistic) Morphology Mac Application. I often have to check if the Words in a given Text are in a huge List of Words (~1.000.000).
My Question is: How do i store these Lists ?
I use a .txt File to store the Words and create an NSSet from this File, which survives as long as the Application is launched.
I use a Database like SQLite.
Some points:
I think the focus should be on speed, because the analysis is triggered by the user and this comparisons make the largest part of the computation.
The Lists may change via updates.
I used CoreData and MySQL before, so (i think) i could realize both.
I have read a lot about the pro/cons of Database vs. File but i never thought its my usecase.
I dont know if its relevant which technik i use, because the size of these Files is relatively small (~20MB) and even with a lot of supported Languages, only 3-4 of this files will be loaded into memory at the same time.
Thanks! Danke!
Reading this article for instance, writing an NSDictionary to a plist looks pretty easy. Now, if I just want to modify one single row of an existing plist: Is there any way to update the row without re-writing the whole file?
Like "when updating a row in a database table, I don't have to rewrite the whole table"?
Thanks,
J.
First : plist is for very trivial data, so there should not be the question of optimisation of reading and writing it. As if you need to optimise that, that means you need to change your application design.
Second : plist is basically an xml file, so of course you can use xml parsers.
Theoretically, you could do modifications faster under the condition that the lengths of the string representation of your new value takes up precisely as many characters as that of the old value. However, this would be a bad case of micro-optimization: unlike a database where rewriting an entire table may take considerable time, rewriting a plist in its entirety should go unnoticed, as far as the timing is concerned. Your code to locate and overwrite the old value in a file would not be pretty by any standard. It has no chance of matching the clarity of a three-line "read-modify-write" code fragment that rewrites the whole thing.
This assumes that you are using your property list for its intended purpose, which is storing relatively small amounts of data. If you are using a plist to store moderate to large amounts of data, perhaps you need to switch to using a database, where updating individual rows is permitted.
Where is the sense in that?
Despite what has already been said, that plist, who use XML, is designed for small amounts of data and that it could work properly only when the new value does not make any change to the length (string representation within the XML) of your value, there is hardly any bargain to make.
Frankly I do not know what the cluster (or however the smallest fraction of allocable disk space is named in iOS' file system) size is but I would not expect it to be much smaller then the average size of a typcal plist file. In all file systems that I know a cluster will allways be written in one go. Even if the programmer just changes a byte and tries to write only that one byte back to the file, the OS will allways write the full cluster on disk (or whatever there is that we still call a disk :).
Meaning - even if you try hard, you will hardly gain anything from that attempt.
Unless of course, your data structure is rather big and probably complex for a plist file. In that case, as it has been said already, consider a change to the data storage method that you are using.
From an other answer:
You have:
a plist file
a container (for example, NSMutableArray) in which you load this plist
a table view which takes values from this container.
To modify plist through table view:
change value in container
write container back to plist file.
I have a list of about 10,000 phrases (1-5 words each). When the user starts to type in the searchbar, I want to display a tableview that filters through these phrases to find matches. ie: it will function like auto-fill in your browser.
My question is: What is the best way to store this data? Should I just put it in an array that gets initialized when the user searches? Or should it be stored in an external file?
(I am working with iOS).
Thanks!
You could easily do it with an array, but the performance would be very poor.
It would be best to have it in a SQLite (or Core Data) database and search that.
I think having it in a file could be even worse performance than the array.
Save it in a SQLite or Core Data database. You could also use a .plist file, although that might take longer to read through.
I am planning a Seaside app to hold text, a single instance which may be up to, say, 5Mb. What kind of object is best for this?
I would also like to do some iterations over this text.
Thanks, Vince
Edit: Thanks for your replies thus far. The file is a CSV file that takes ~40 minutes to generate from a legacy finance system, so it must be pre-generated and stored. Each line is a customer record and I need to pull each one out and use the values as and when the customer logs in. Customer access is not predictable and interfacing with the legacy system to generate each line on the fly is a very last resort.
Given that the file takes that long to generate and that you need more-or-less random access to the file later on, I would opt for parsing the file and keeping the structured data in memory afterwards.
There is a CSV Parser project on Squeaksource that you can use. It will create a structured object tree of the CSV records that you can use.
Use an external Text file and some instance of a specific class as representation of that file. Use the oop of the object as the name of the file.
Just use a collection of customers, and fill it from the CSV, as Johan said. Depending on your accessing needs you can use a Dictionary or an OrderedCollection to hold it.
5 megs is nothing. Don't worry about that.
If you can't reify those CSV records into objects (after parsing and instantiating them), then a Collection of Strings or even Streams would be just fine.
If you need keyed lookup then a Dictionary or LookupTable would do the job.
I had 100 megs of text data in memory (1 millon rows), and even persisted in the image (image save) with no problems.
Regards.
I am working on a small roguelike game, and need some help with creating save games. I have tried several ways of saving games, but the load always fails, because I am not exactly sure what is a good way to mark the beginning of different sections for the player, entities, and the map.
What would be a good way of marking the beginning of each section, so that the data can read back reliably without knowing the length of each section?
Edit: The language is C++. It looks like a readable format would be a better shot. Thanks for all the quick replies.
The easiest solution is usually use a library to write the data using XML or INI, then compress it. This will be easier for you to parse, and result in smaller files than a custom binary format.
Of course, they will take slightly longer to load (though not much, unless your data files are 100's of MBs)
If you're determined to use a binary format, take a look at BER.
Are you really sure you need binary format?
Why not store in some text format so that it can be easily parseable, be it plain text, XML or YAML.
Since you're saving binary data you can't use markers without length.
Simply write the number of records of any type and then structured data, then it will be
easy to read again. If you have variable length elements like string the also need length information.
2
player record
player record
3
entities record
entities record
entities record
1
map
If you have a marker, you have to guarantee that the pattern doesn't exist elsewhere in your binary stream. If it does exist, you must use a special escape sequence to differentiate it. The Telnet protocol uses 0xFF to mark special commands that aren't part of the data stream. Whenever the data stream contains a naturally occurring 0xFF, then it must be replaced by 0xFFFF.
So you'd use a 2-byte marker to start a new section, like 0xFF01. If your reader sees 0xFF01, it's a new section. If it sees 0xFFFF, you'd collapse it into a single 0xFF. Naturally you can expand this approach to use any length marker you want.
(Although my personal preference is a text format (optionally compressed) or a binary format with length bytes instead of markers. I don't understand how you're serializing it without knowing when you're done reading a data structure.)