I have some 1000 key-pair values that I will use in my j2me application, reading it from a resource file. However I will be using only a few of those values at any time, say 10, based on the record number being generated inside the application logic. Loading all the values into memory and then looking up is fairly not an efficient option as I will not be using all the records. Is there a better scheme to store the values in the file, some indexing or something so that I can retrieve those key-pair values by skipping the amount of bytes in the file to reach and read the appropriate record? As this is a resource file in the jar there wont be any modifications to it.
+1
A:
If you know the record length when they are created, you could write the records out in binary format to a file. But at the start of each record, you could first write a number indicating its size in bytes and use a RandomAccessFile to access the records by moving the file pointer. But in terms of speed, loading into memory will be faster than reading from a file, but if memory is at a premium, then a file wouldn't be a bad way to go.
Jeff
Jeff Storey
2009-10-03 20:39:19
Thanks, but this method of writing the number of bytes before each record does give the advantage of indexing. Suppose, if I need to fetch the 512th record. I am not directly skipping n-bytes to get the record, but rather I will have to get this record size and then skip that amount of bytes
Ram
2009-10-05 06:44:16
True, but you store the record sizes in memory, or more specifically, store the number of bytes required to get to rec1 (0 bytes), rec2 (rec1.length), rec3 (rec1.length+rec2.length), etc. While you still need to store this in memory you're only storing an int (or long) for each record rather than the entire record.
Jeff Storey
2009-10-05 11:55:30
Also, I'm assuming each record is not a constant size. If it is, then you know it's just recLength * (recNum-1)
Jeff Storey
2009-10-05 11:56:25
You mean to say that storing the indices as a separate file and use that to read the contents from the original file or otherwise?
Ram
2009-10-05 16:42:52
I mean to store the indices in the file before the record and then read in the indices at the start of the app, then you can quickly jump to that record in the file.
Jeff Storey
2009-10-06 01:47:44
Thanks Jeff, sounds fine to me
Ram
2009-10-06 05:46:28
A:
Skipping bytes in a compressed resource file inside a jar is not really going to be optimal either and the implementation of InputStream you get as a result of calling Class.getResourceAsInputStream() may be fragmented if you plan on running your application on several devices.
EDIT after additional info in comment:
It could be that the best way to do this is actually to store the (question, answer) data in 1000 different classes.
It's going to feel very weird as a solution but the class loader should only load the 10 classes you actually use, you can generate the 1000 source files with a simple J2SE program and you can load 10 random classes based on an integer inside their name using java.lang.Class.forName().
If the jar file doesn't become too big to use, you're basically relying on the indexing of its zip file format for the class loader performances...
QuickRecipesOnSymbianOS
2009-10-05 12:09:03
It is something like a crossword puzzle, where I pick up some random 10 question answer pairs from the 1000 and create the puzzle. Getting over the network in not an option because this is a standalone game. So generating those ten random records and wading through the stream is not efficient and loading all the thousand is not efficient either. So I am try to get a best-of-both-worlds solution
Ram
2009-10-05 16:41:19