[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Strange performance hit for insert-file-contents-literally()
From: |
Nordlöw |
Subject: |
Strange performance hit for insert-file-contents-literally() |
Date: |
Thu, 26 Nov 2009 23:58:10 -0800 (PST) |
User-agent: |
G2/1.0 |
I am implementing a package for doing recursive file system magic-
detect and scan/search/grep for pattern.
In this process I have stumbled across a strange performance problem;
If I want to grep for raw binary (literal) patterns, I thought that
(benchmark-run 1 (with-temp-buffer (buffer-disable-undo) (insert-
file-contents-literally "~/pnw.tar.gz" nil)))
would given optimal performance but it turns out that
(benchmark-run 1 (save-excursion (set-buffer (find-file-noselect "~/
pnw.tar.gz" t t))))
is about 11 times faster on my laptop PC (the first time its called of
course, the second time it reuses the open buffer so that doesn't
count)!.
As find-file-noselect() uses insert-file-contents-literally() it must
disable some stuff that find-file-literally() doesn't. The question is
what?
I would prefer no to be forced to use find-file-noselect() as this
does other unneccessary stuff I don't need.
It also reuses the buffer if its already open which is not always what
I want with compressed files for example.
My logic namely detects the file magic headers for compressed files
and then reopens them non-literally using jka-compr in order to detect
their underlying (decompressed) type like the unix program "file"
does.
Is this maybe a bug?
I am currently using Emacs CVS.
Thanks in advance for all tips,
Nordlöw
- Strange performance hit for insert-file-contents-literally(),
Nordlöw <=