对于少量信息，java 文件 i/o 或 derby 哪个更快？
我正在用 java 编写一个小代理，它将与其他代理玩游戏。 我想在程序运行之间保留少量状态（最多大约 1kb），以便我可以根据过去的成功尝试调整代理的性能。 本质上，我将在每个游戏开始时读取少量数据，并在结束时写入少量数据。 看起来我有 2 个选择，文件 I/O 或 derby。 两者都有速度优势吗？ 或者对于这么少量的数据来说真的不重要吗？
I'm writing a small agent in java that will play a game against other agents. I want to keep a small amount of state (probably approx. 1kb at most) around between runs of the program so that I can try to tweak the performance of the agent based upon past successes. Essentially, I will be reading a small amount of data at the beginning of each game and writing a small amount at the end. It seems like I have 2 options, file I/O or derby. Is there a speed advantage to either? Or does it not really matter for such a small amount of data?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于 1kb 的数据，最好使用标准文件 IO。 最有可能的是，您可以将整个对象树序列化到磁盘，并在再次启动时进行简单的反序列化。 如果您想变得更奇特，可以使用 JAXB 序列化为 XML 而不是二进制文件。
尽管我喜欢将每个问题都应用到数据库解决方案中，但我认为这在这里不太实用。 除非您对数据库特定功能有特殊需求，否则使用数据库会带来大量开销、复杂性和维护问题。
您可能真正想要使用数据库的唯一领域是如果您有很多小对象/行并且经常对数据执行排序和过滤。 但即便如此，您也可以在内存中保留十几个有序列表，并以更少的资源获得更好的性能，并且不会遇到令人头疼的数据库问题。
如果您确实认为在这种情况下需要数据库，请考虑 HSQL。 我不认为它是一个真正的数据库，但它是一个可以持久保存到文件中的内存数据库。 开销低、复杂性低、故障点相对较少。 另外，如果您需要编辑持久数据，可以使用文本编辑器来完成。 关于德比不能这么说。
With 1kb of data, you are better off using standard file IO. Most likely, you could serialize the entire object tree to disk and dismply deserialize when you startup again. If you wanted to get fancy, you could use JAXB to serialize to XML instead of binary files.
As much as I love to fit every problem to the database solution, I don't think that's very practical here. Unless you have some special need of database specific capabilities, you are introducting a lot of overhead, complexity, maintenance problems by using a database.
The only areas where you might really want to use the database is if you have a lot of small objects/rows and you frequently perform sorts and filters on the data. But even then, you could probably keep a dozen in-memory ordered lists and get better performance with less resources and without the headache of a database.
If you really think you need a database in this scenario, consider HSQL. I don't consider it a real database, but it's a in-memory database that can persist to a file. Low overhead, low complexity, and relatively few points of failure. Plus, if you need to edit the persisted data, you can do so with a text editor. Can't say that about Derby.
考虑到这些对象可能因文件大小而异，并且您的计算机规格（总线速度、高清速度）会影响这一点，唯一确定的方法是编写您自己的基准测试。 只需创建一个简单的for循环，从1数到1000，并一遍又一遍地读取循环内的文件（但不要创建和销毁循环内的对象，只需关注读取部分）。
当然，这整个练习充满了预优化的味道，这可能会导致不良的编码习惯。 只需以最易读、最简单的方式编写代码，如果存在速度问题，请根据需要进行重构。
但由于数据量很小，我认为这并不重要。
Considering that these objects can vary per file size, and your computer's specs (bus speed, HD speed) affect this, the only way to be sure is to write your own benchmark. Just create a simple for loop, count from 1 to 1000, and read the file inside the loop over and over (but do not create and destroy the objects inside the loop, just focus on the reading part).
Of course this whole exercise reeks of pre-optimization, which can lead to bad coding habit. Just write your code in the most readable, simple fashion, and if there is a speed problem, refactor as needed.
But since it's a small amount of data, I would say it won't matter.