diff options
author | Panu Matilainen <pmatilai@redhat.com> | 2012-07-02 14:30:24 +0300 |
---|---|---|
committer | Panu Matilainen <pmatilai@redhat.com> | 2012-07-02 15:02:11 +0300 |
commit | bf3a14a86682e4bf341eed4d6d7050ef57b1ccc2 (patch) | |
tree | 16ce69b5a7b2813f64b0012b6947e7fce40c948b /configure.ac | |
parent | 105f91fc9a0afd9f8d29491c909833bdf2228f8a (diff) | |
download | librpm-tizen-bf3a14a86682e4bf341eed4d6d7050ef57b1ccc2.tar.gz librpm-tizen-bf3a14a86682e4bf341eed4d6d7050ef57b1ccc2.tar.bz2 librpm-tizen-bf3a14a86682e4bf341eed4d6d7050ef57b1ccc2.zip |
Dont use mmap() for anything, axe the code instead
- Commit 4cb02aa928d3e41f636d0e01356c7a3cb51018ee asked to see
what breaks when mmap() is used, now we know: large package support
broke when enabling it. Could be fixed of course by eg adding
a size cap to the fsm part as well, but just doesn't seem worth it:
I fail to measure any meaningful performance improvement from mmap
usage in either case, and added complexity for what is close to
zero benefit just doesn't make sense... and various sources in fact
note the rpm usage (read through the entire file sequentially) as one
of the cases where mmap() is NOT beneficial due to mmap() high
setup + teardown cost + page fault speed (or lack of thereof).
Diffstat (limited to 'configure.ac')
-rw-r--r-- | configure.ac | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/configure.ac b/configure.ac index cd11d26e0..24d0d2c54 100644 --- a/configure.ac +++ b/configure.ac @@ -480,8 +480,6 @@ AC_TYPE_PID_T AC_TYPE_SIZE_T dnl Checks for library functions. -AC_FUNC_MMAP - AC_CHECK_FUNCS(putenv) AC_CHECK_FUNCS(mempcpy) AC_CHECK_FUNCS(fdatasync) |