From: Jeff Clough <jeff@chaosphere.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Lisp Questions - reading a file and processes stalling
Date: Sun, 21 Mar 2010 23:22:29 -0400 [thread overview]
Message-ID: <m3bpehghvu.fsf@logrus.localdomain> (raw)
In-Reply-To: 878w9lqepg.fsf@galatea.lan.informatimago.com
pjb@informatimago.com (Pascal J. Bourguignon) writes:
> insert-file-contents is really the lightest weight of getting the
> content of a file into a buffer. Why do you doubt it?
When I step through my function with the debugger I see
insert-file-contents doing a lot of work. I haven't counted, but
there's at least a dozen calls going on and that overhead
seems...excessive. For instance, I can see it trying to match file
extensions in several batches, I assume as an attempt to determine the
correct mode for the buffer.
I can't seem to find a way of telling Emacs to put the contents of the
file in a buffer then move along.
> Otherwise you may like find-file-literally, but it does more work.
Interesting, and I see the related function
insert-file-contents-literally. I'll take a look at it, but the
statement "it does more work" probably means it's not going to be much
different.
> Openning thousands of files will be slow anyways.
>
> The standard solution is to build an index with the data you need, so
> that you can just open one index file.
Yeah, that's what I'm doing now. Realistically, it's unlikely that I'll
ever have to process the entire set of files more than once (to generate
the index), and can just process additions as they come.
I'm just poking at the code, trying to figure out both what's going on
under the hood and how to do things better.
>> Second, I have Emacs running an external program as a process. When
>> some other lengthy operation is happening elsewhere in Emacs (like Gnus
>> is trying to display the headers for a group*), that process stalls,
>> then picks up where it left off once the operation is done. Is there
>> any way to make Emacs not steal the resources from this process, or am I
>> doing something hopelessly wrong?
>
> No, there's no way. GNU emacs is not multi-threaded.
>
> My solution is to run ERC and GNUS each in its own instance of emacs.
Yeah, I didn't think so but it was worth asking the gurus. I'll
probably just deal with it since I'm generally happier with just one
instance of emacs. For now, at least.
Thanks!
Jeff
next prev parent reply other threads:[~2010-03-22 3:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 0:41 Lisp Questions - reading a file and processes stalling Jeff Clough
2010-03-22 2:20 ` Pascal J. Bourguignon
2010-03-22 3:22 ` Jeff Clough [this message]
2010-03-22 16:02 ` Stefan Monnier
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=m3bpehghvu.fsf@logrus.localdomain \
--to=jeff@chaosphere.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).