unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Nordlöw <per.nordlow@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Strange performance hit for insert-file-contents-literally()
Date: Fri, 27 Nov 2009 01:25:36 -0800 (PST)	[thread overview]
Message-ID: <b12b85bc-c92b-498b-9801-ef84d90e2892@k17g2000yqh.googlegroups.com> (raw)
In-Reply-To: 8366552c-0494-4dd6-9346-aa9f3ced4ea6@c34g2000yqn.googlegroups.com

On Nov 27, 9:26 am, Nordlöw <per.nord...@gmail.com> wrote:
> On Nov 27, 8:58 am, Nordlöw <per.nord...@gmail.com> wrote:
>
>
>
>
>
> > 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
>
> I also need the sub-file aspect (BEG END) of  insert-file-contents-
> literally().
>
> I could get by with
> - find-file-noselect() when I want to scan the whole file a la grep
> and
> - insert-file-contents-literally() when I only want to open a part
> (typically beginning or end) when I want to detect its contents/type a
> al file.
>
> How can I detect if a file is already opened before calling find-file-
> noselect() on it?
> Reason: I don't want files that don't match my grep pattern to remain
> opened (kill its buffer).
>
> Please help! This package I am writing will soon be release to the
> public (EmacsWIki) and will be really useful!
> It is an elegant (I think) merge of the UNIX command line tools find,
> tree, file, grep and file all implemented in pure emacs lisp (making
> it independent of underlying OS read it will work on windows) with its
> own nice colored presentation/hit-navigation mode. It is compatible
> with TRAMP and does auto-compression (jka) of files that are being
> searched and supports emacs-style regexps (of course) making it simply
> the ultimate file system scanning tool for Emacs users.
>
> /Nordlöw

Note: The observed difference is for really large files ~250Mb in my
case. Not for files of size ~1Mb. I don't what the size limit for the
difference is.

/Nordlöw


  reply	other threads:[~2009-11-27  9:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-27  7:58 Strange performance hit for insert-file-contents-literally() Nordlöw
2009-11-27  8:26 ` Nordlöw
2009-11-27  9:25   ` Nordlöw [this message]
2009-11-27 15:17     ` Drew Adams
2009-11-27 15:17   ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b12b85bc-c92b-498b-9801-ef84d90e2892@k17g2000yqh.googlegroups.com \
    --to=per.nordlow@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).