问题标签 [mappedbytebuffer]

据我所见MappedByteBuffer，在调用FileChannel.map“映射”文件内容到内存后，但不一定将整个文件加载进去。所以，如果我开始阅读例如在 pos(0)，页面可能实际上是从那时的磁盘，例如文件的前 4096 字节，进入主内存（在堆之外，因为它是直接内存缓冲区）。

我的问题是 - 如果我load()在缓冲区上调用方法会发生什么？考虑到这是我映射的数量，是否会尽量将整个文件映射到内存中，例如准确加载 1GB 的数据？

I'm new to java ...in my current project I need to read and write a very huge text file (1 GB - 5 GB) ... first i used this classes : BufferedReader and BufferedWriter

this classes works very good but not for Huge files...

then I used MappedByteBuffer for the read() method (I dont't know how to write a file using this class) :

But still can't read large files(over 30-40 MB), even the NotePad is faster than my app :))

and also another problem is I don't know how to change encoding in second way(for example "UTF-8", "ANSI",...)

so guys, please tell me which is the best way to read and write laaaarge files? any idea?

长期读者，第一次海报。

我在从一组二进制文件中快速读取数据时遇到了一些麻烦。ByteBuffers 和 MappedBytBuffers 提供了我需要的性能，但它们似乎需要初始运行才能预热。我不确定这是否有意义，所以这里有一些代码：

所以这需要大约 7 秒才能运行，但如果我再次运行它，它会在 10 毫秒内完成。似乎它需要进行某种初始运行来设置正确的行为。我发现通过做这样简单的事情是可行的：

这大约需要 2 秒，如果我随后运行 MappedByteBuffer 过程，它会在 10 毫秒内返回数据。我只是不知道如何摆脱初始化步骤并在 10 毫秒内第一次读取数据。我已经阅读了有关“热身”、JIT 和 JVM 的各种内容，但都无济于事。

所以，我的问题是，是否有可能立即获得 10 毫秒的性能，还是我需要进行某种初始化？如果是这样，请问最快的方法是什么？

该代码旨在运行大约一千个相当大的文件，因此速度非常重要。

非常感谢。

我遇到了 MappedByteBuffer 的问题，特别是它在内部的工作方式。我理解它的方式缓存完全由操作系统完成。因此，如果我从文件中读取（使用 MappedByteBuffer），操作系统将从硬盘驱动器读取整个页面并将页面保存在 RAM 中，以便在再次需要时更快地访问。这也允许为访问同一文件的多个应用程序/进程提供共享缓存。这个对吗？

如果是这样，如何使此缓存无效？只是重新初始化映射对象不应该工作。我编写了一个从硬盘驱动器读取大量数据的应用程序。我需要做一些基准测试，所以我需要在需要时清除这个缓存。我尝试使用“echo 3 > /proc/sys/vm/drop_caches”，但这并没有什么不同，所以我认为它不起作用。

我正在尝试从 Android 上的 Uri 读取内容，并且我需要通过 nio.ByteBuffer 将最终对象类型传递给底层 SDK。

我可以通过 ContentResolver 获得 InputStream，但没有找到用 nio.ByteBuffer 包装它的方法。

有没有办法在 Android 上将 Uri 内容转换为 nio.ByteBuffer ？

我的问题是操作系统是否会尊重插入顺序（即最后写入，最后写入磁盘）或者顺序将是不可预测的。例如：

它总是最后写的，最后写的还是我在这里遗漏了什么？

这是我正在运行的代码：

在按下某个键之前，我试图在 FAR Manager 中手动删除该文件。但 FAR 说文件被锁定：

只有在按下一个键后，应用程序才会终止，我可以删除文件。

我的代码有什么问题？

目前我正在通过以下方式从映射字节缓冲区填充 FloatBuffer：

但我怀疑有更好的方法来做到这一点，而不是遍历所有位置。缓冲区中可以有很多顶点（最多 65536）。

这似乎有效：

但是，OpenGL 中的这个函数会向 GPU 发送太多数据吗？还是只是从当前位置到极限？

我用 FNV 将字符串散列成整数。我将它们存储在 MappedByteBuffer 中的自定义哈希表中，以希望改善对堆内存中同一个表的内存访问，并在程序中断时为文件提供一致的表存储。这种堆外 MappedByteBuffer 在速度方面是否可能优于基于堆的哈希表？JDK HashMap 太慢了。

我一直在用现有的 Java 代码开发一个 C++ 项目。我从同一个测试文件中读取了以下 C++ 代码和 Java 代码，该文件由数百万个整数组成。

C++：

爪哇：

void swapElem(arr)在 C++ 和 Java 中是相同的。它比较和修改数组中的值，但原始代码有点长，无法在此处发布。出于测试目的，我将其替换为以下函数，因此循环不会是死代码：

我假设 C++ 版本的性能应该优于 Java 版本，但测试给出了相反的结果——Java 代码几乎是 C++ 代码的两倍。有什么方法可以改进 C++ 代码吗？

我觉得可能mmapFile+offset在 C++ 中重复了太多次，所以它是 O(n) 加法和 O(n) 加法offset+=sizeof(int)，其中 n 是要读取的整数数。对于 Java 来说IntBuffer.get()，它只是直接从缓冲区的索引中读取，所以除了缓冲区索引的 O(n) 递增 1 之外，不需要加法操作。因此，包括缓冲区索引的增量，C++ 需要 O(2n) 加法，而 Java 需要 O (n) 补充。当涉及到数百万个数据时，它可能会导致显着的性能差异。

按照这个想法，我修改了C++代码如下：

我认为会有轻微的性能提升，但没有。

谁能解释为什么 C++ 代码比 Java 代码运行得慢？谢谢。

更新：

我不得不道歉，当我说 -O2 不起作用时，我的结果出现了问题。我搞砸了 Makefile，所以 C++ 代码没有使用 -O2 重新编译。我已经更新了性能，使用 -O2 的 C++ 版本的性能优于 Java 版本。这可以解决问题，但如果有人想分享如何改进 C++ 代码，我会跟进。一般来说，我希望它比 Java 代码快 2 倍，但目前不是。谢谢大家的意见。

编译器：g++

标志：-Wall -c -O2

Java版本：1.8.0_05

文件大小：552MB，全部为 4 字节整数

处理器：2.53 GHz Intel Core 2 Duo

内存 4GB 1067 MHz DDR3

更新基准：

版本时间（毫秒）

C++：~1100

爪哇：~1400

C++（没有 while 循环）：~35

Java（没有 while 循环）：~40

我在这些代码之前有一些东西会导致〜35ms的性能（主要用-1填充数组），但这在这里并不重要。