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

iOS Which performance is better?

mikezang

mikezang

macrumors 6502a
Original poster
May 22, 2010
939
41
Tokyo, Japan
I have about 4000 binary file that stored stock data, the file name is the stock code, so that I can access specific stock data very fast.

Now I try to port this to iPad, I want to know which one will have a better performance for reading and updating data.

1. Use 4000 files to store data as like in PC
2. Use Core Data and convert 4000 files to Core Data Model
 
Well, I'd recommend Core Data in most cases. It does most of the heavy lifting for you. I got a 7,000 entry database application running on my 1st gen iPod touch, and it's running rather smoothly.
 
Most likely core data or sqlite directly will be faster or better. Really you should design your app so you can easily change between the two data storage models to test the difference.

In fact, opening one file and reading its contents might be faster than a core data query. But having a large number of files in your app bundle will be a problem.
 
I've seen reports that it can take a long time for the app to upload when starting to debug, both on device and Sim. There's also a possible issue with backups, which have been reported to be very long if there are a lot of files in the Documents folder, although that may not be an issue if all the files are in the app bundle.
 
PhoneyDeveloper said:
I've seen reports that it can take a long time for the app to upload when starting to debug, both on device and Sim. There's also a possible issue with backups, which have been reported to be very long if there are a lot of files in the Documents folder, although that may not be an issue if all the files are in the app bundle.
Click to expand...

It takes quite a while to build the app onto the device as each file has to be copied. It may be that copying 1000 1Kb files takes longer than 1 1000Kb file. But in actual performance on the device (in the final app). I get very good performance out of this approach: I need to load a lot less data into memory as I am only loading exactly what I need when I need it.
 
So you confirm that having a lot of files is a problem for debugging but the app runs OK when not debugging. I assume you didn't try the database method, else you would have mentioned it.

Fair enough. I'm not clear that one way will give better performance than the other. Searching for a file to open in one big folder or in a bunch of subfolders inside the app bundle might take time also. Don't really know.
 
In my case, only one file should be read when the stock chart is showed.

Then I don't need to design data model as all files already exist.

At last, I have to update those files everyday.

But I am not sure, where is the Document folder put? I checked all samples, I didn't find any document folder.
 
mikezang said:
In my case, only one file should be read when the stock chart is showed.

Then I don't need to design data model as all files already exist.

At last, I have to update those files everyday.

But I am not sure, where is the Document folder put? I checked all samples, I didn't find any document folder.
Click to expand...

You should have read and understood all of the iPhone Application Programming Guide. In this particular case the Getting Paths to Application Directories.

Note that the documentation is more important and useful than the samples. Learn to use it.
 
If you need to update these files every day then that's a little different. Files in the app bundler aren't writable. You need to put them into the Documents folder when the app runs. That will affect the backup time for the app, possibly badly. Having one or a few database files in the Documents folder will almost certainly be better in that case.
 
PhoneyDeveloper said:
If you need to update these files every day then that's a little different. Files in the app bundler aren't writable. You need to put them into the Documents folder when the app runs. That will affect the backup time for the app, possibly badly. Having one or a few database files in the Documents folder will almost certainly be better in that case.
Click to expand...
What do you mean database files? do you mean SQLite files?
Can you tell me some more detail information?
 
I tested those samples code, I want to have a sample to read/write files in document folder, there is no such sample.
 
I think for your application, any difference is likely not to be noticeable, because presumably you will be displaying a chart, and producing the chart is going to take far more processor time than reading the file.

Except for the issue of backups which somebody else pointed-out above, the files are likely to be quicker. But moot because reading the files isn't your bottleneck.

I'd go with a database for versatility.

If you do go with files, and you really think there is an issue with read time, consider mapping the file into memory. Then, there really is no explicit "read". The OS will read the file in the most efficient way possible when the memory it's mapped to is accessed. The OS will take care of caching, and if you only access some of the memory, only that part would be read. This would be the most efficient I/O, but still it's beating a dead horse.
 
It is said the bundle can't be updated, is it true?

I have to use files in document folder if it is true...

At the moment, I hope that I can find a sample that can tell me how to read/write files in document folder.

I will try core data if it is in a bad performance after I create my first app.
 
Bundles can't be updated. Only the data directory. It is common to have some files in the bundle that you immediately copy to the data directory upon first startup. Then, you can download new data and overwrite or append-to the files in the data directory.

Efficiency isn't a good reason for choosing CoreData. Versatility is. You really are not going to have a problem with speed using either approach, unless you write really, really bad code. Trust me.

It sounds like you are uncomfortable with learning Core Data, so I would stick with the binary files. You apparently already have code that works. (Though you'll have to re-write it in Objective-C.) Later, you might find you want to switch to Core Data because you will need to jump through fewer hoops to maintain your data.

But it's hoop-jumping, not speed that is going to be the reason to switch. You are trifling over a non-issue.
 
jtara said:
You apparently already have code that works. (Though you'll have to re-write it in Objective-C.)
Click to expand...

It may not be necessary to rewrite working code in Objective-C.

If the original code is in standard C or C++, and uses only standard Posix capabilities, then it's possible that no rewrite will be needed. There are limitations regarding libraries, but otherwise C and C++ are viable.

However, any code that works with a GUI, or does other things too numerous to easily list here, will probably require rewriting. Or at least rewriting some parts of it.

There's really no way to know if existing code will need a rewrite, without knowing more details about the existing code.
 
chown33 said:
It may not be necessary to rewrite working code in Objective-C.

If the original code is in standard C or C++, and uses only standard Posix capabilities, then it's possible that no rewrite will be needed. There are limitations regarding libraries, but otherwise C and C++ are viable.

However, any code that works with a GUI, or does other things too numerous to easily list here, will probably require rewriting. Or at least rewriting some parts of it.

There's really no way to know if existing code will need a rewrite, without knowing more details about the existing code.
Click to expand...
The code is in C#, I don't want to use that GUI, I just want to use the basic logic.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back