summaryrefslogtreecommitdiff
path: root/configure.ac
diff options
context:
space:
mode:
authorPanu Matilainen <pmatilai@redhat.com>2012-07-02 14:30:24 +0300
committerPanu Matilainen <pmatilai@redhat.com>2012-07-02 15:02:11 +0300
commitbf3a14a86682e4bf341eed4d6d7050ef57b1ccc2 (patch)
tree16ce69b5a7b2813f64b0012b6947e7fce40c948b /configure.ac
parent105f91fc9a0afd9f8d29491c909833bdf2228f8a (diff)
downloadlibrpm-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.ac2
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)