Which is faster for small amount of information, java file I / O or derby?
I am writing a small agent in java that will play a game against other agents. I want to save a small amount of state (probably about 1kb maximum) between program runs so that I can try to tune the agent's performance based on past successes. Basically, I will read a small amount of data at the beginning of each game and write a small amount at the end. I seem to have 2 options, file I / O or derby. Is there a speed advantage? Or doesn't it really matter for such a small amount of data?
source to share
Given that these objects can change based on file size, and your computer specs (bus speed, HD speed) affect this, the only way to make sure you write your own test. Just create a simple loop, count from 1 to 1000, and read the file inside the loop over and over again (but don't create or destroy objects inside the loop, just focus on the reading part).
Of course, this whole exercise stinks of pre-optimization, which can lead to bad coding habits. Just write your code in the most readable, simplest way possible, and if there is a speed issue, refactor as needed.
But since this is a small amount of data, I would say it doesn't matter.
source to share
With 1kb of data, you're better off using a standard IO file. Chances are you can serialize the entire object tree to disk and parse the deserialization on rerun. If you want to get fancy, you can use JAXB to serialize to XML instead of binaries.
As much as I like to fit each problem for a database solution, I don't think it is very practical. Unless you have special capabilities for specific databases, you introduce a lot of overhead, complexity, and maintenance issues using a database.
The only areas where you really want to use a database is if you have a lot of small objects / rows and do sorts and filters on the data often. But even then, you could probably keep a dozen order lists in memory and get better performance with less resources and no database headache.
If you really think you need a database in this scenario, consider HSQL. I don't consider this to be a real database, but it is an in-memory database that can be stored in a file. Low overhead, low complexity, and relatively few failures. Alternatively, if you need to edit the saved data, you can do so with a text editor. I can't say what about Derby.
source to share