visiting large files

visiting large files

[mehran khajavi]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Hi,
I have a question:
How can I visit large files (about 100mg) and edit them with a high speed
and no high CPU processing?
when i open a same file with vim it will process it so faster than emacs
i searched a little and found http://www.emacswiki.org/emacs/vlf.el but it
doesn't solve my problem

I tested the file with also the fundamental-mode of emacs on it's buffer,
but not good enough

I'm running emacs 24 pretest on GNU/Linux

-- 
-----
Mehran Khajavi
http://mehran.khajavi.ir

[-- Attachment #2: Type: text/html, Size: 790 bytes --]

Re: visiting large files

[Eli Zaretskii]

> From: mehran khajavi <sinoohe.mkh@gmail.com>
> Date: Tue, 4 Oct 2011 14:08:16 +0330
> 
> How can I visit large files (about 100mg) and edit them with a high speed
> and no high CPU processing?
> when i open a same file with vim it will process it so faster than emacs
> i searched a little and found http://www.emacswiki.org/emacs/vlf.el but it
> doesn't solve my problem
> 
> I tested the file with also the fundamental-mode of emacs on it's buffer,
> but not good enough

Does it help to visit the file with

  M-x find-file-literally RET filename RET

?  If not, please tell what kind of file is that.  Can you make it
available somewhere?

Re: visiting large files

[mehran khajavi]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

wow
great
thanks
my problem fixed!

On Tue, Oct 4, 2011 at 4:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: mehran khajavi <sinoohe.mkh@gmail.com>
> > Date: Tue, 4 Oct 2011 14:08:16 +0330
> >
> > How can I visit large files (about 100mg) and edit them with a high speed
> > and no high CPU processing?
> > when i open a same file with vim it will process it so faster than emacs
> > i searched a little and found http://www.emacswiki.org/emacs/vlf.el but
> it
> > doesn't solve my problem
> >
> > I tested the file with also the fundamental-mode of emacs on it's buffer,
> > but not good enough
>
> Does it help to visit the file with
>
>  M-x find-file-literally RET filename RET
>
> ?  If not, please tell what kind of file is that.  Can you make it
> available somewhere?
>
>


-- 
-----
Mehran Khajavi
http://mehran.khajavi.ir

[-- Attachment #2: Type: text/html, Size: 1479 bytes --]

Re: visiting large files

[Eli Zaretskii]

> From: mehran khajavi <sinoohe.mkh@gmail.com>
> Date: Tue, 4 Oct 2011 17:14:25 +0330
> Cc: help-gnu-emacs@gnu.org
> 
> wow
> great
> thanks
> my problem fixed!

That's good to know.

But could you perhaps share the information about the file anyway?
For example, the following information would be useful to see if there
is some bug in Emacs 24 or some speedup we should look for:

  . How long were the lines in this file, and how many lines are
    there?

  . Are there any empty lines in this file, and if so, how many lines
    are between each pair of empty lines?

  . I'm guessing this file is an ASCII file (otherwise,
    find-file-literally would make it hard or impossible to read), but
    please confirm that guess.

  . What was the major mode that Emacs used to visit this file?

  . Can you perhaps show a typical short fragment from the file?

Thanks in advance.

Re: visiting large files

[Eli Zaretskii]

> From: mehran khajavi <sinoohe.mkh@gmail.com>
> Date: Tue, 4 Oct 2011 18:56:03 +0330
> Cc: help-gnu-emacs@gnu.org
> 
> I'm comparing it with vim and vim is so faster than emacs with opening this
> large file(24mg)! also with  find-file-literally
> my file containing sql queries that dumped from MySQL
> lines of file is so long! maybe whole of the file is just a line
> and there is some empty lines there
> find-file-literally makes it  little better but also sometimes hangs(about
> some milliseconds), (when i scroll the file by holding page down and page up
> keys)

This file has 52 lines, each line about 50,000 characters.  Very long
lines are known to slow down Emacs display.  There's a bug report
about this in the bug tracker, so hopefully someone will find a fix
for this.

Thanks for the data.  But in the future, please send it in private
email, there's no need to invade everyone's mailbox with such large
attachments.