[prev in list] [next in list] [prev in thread] [next in thread]
List: jedit-users
Subject: Re: [ jEdit-users ] [ jEdit-devel ] [ jedit-Feature Requests-918301
From: Matthieu Casanova <chocolat.mou () gmail ! com>
Date: 2011-12-09 16:07:20
Message-ID: CAPYM7rWOSOaZcBgVsoEC1KKR0dBajsiY0Lgndnim=QRKYyw+6g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Kazutoshi,
ok about reopening, in fact there are other tricks we can do.
For information I just tested text editors with a big xml file of 220MB,
3.3 million lines but no very long lines.
For the test I opened the file and moved to the end of the file (that's
what takes a lot of time)
Surprisingly, the fastest, by far was jEdit :
here are my results and observations.
jEdit took 2.9 seconds using the trick I untroduced a few months ago :
syntax is not aware of the context. This means that if the xml file starts
with <!-- then end of the buffer will not be highlighted as a comment.
This lead to a possibly wrong syntax highlight but is lightning fast
Emacs took 7 seconds. That's really good too, and it seems they use the
same trick as me, if the buffer starts with a comment, the end of the
buffer is not highlighted with a comment. They have a feature activated
that I had not : softwrap
sciTE took 13 seconds, and used context sensitive syntax, that's very fast.
But if you change the beginning of the file then go again to the end, it
will take 13 seconds again ...
UltraEdit took 18 seconds, and was not aware of the context
Vim took 53 seconds and it seems it was not aware of the context, that's
strange it is so slow.
Notepad++ was the worse, after 2 minutes he was still working so I gave up.
My other ideas about jEit and big files is first an option to remember the
choice (to not popup the windows about big files everytime)
Deactivate soft wrap since it is slow on big files
Deactivate syntax highlight for a single line if the line is too long. I
think it is better than no syntax highlight at all.
Matthieu
2011/12/9 Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
> Hi tvojeho, Thank you for the clarifying post.
>
>
> tvojeho wrote:
>
> > Yes, the discussion strayed off the original topic when I asked about
> > the large buffer handling.
> >
>
> FYI, I remembered the following advice as applying to this case.
> "No Conversations in the Bug Tracker"
> http://www.producingoss.com/**en/bug-tracker-usage.html<http://www.producingoss.com/en/bug-tracker-usage.html>
>
>
> The logic behind that was that I had a large file to work with, was
> > experiencing the long loading with softwrap on, so when I fired up
> > jEdit, went to make a coffee and came back expecting the file
> > loaded - only to encounter the large file dialog - I tried to find out
> > how to switch the dialog off, unsuccessfully.
> >
> >
> > The open topic discussing poor performance with large files seemed
> > like the place to ask. In the past,
> > I have had e-mails bounced back when sending to jedit-users (I
> > subscribed to the list today, I didn't know it was necessary before),
> > so I tacked my question to an open ticket.
> >
> > I also think that the original ticket should not be closed, only my
> > side problem was resolved.
> >
>
> Now the feature request #918301 has been reopend.
> http://sourceforge.net/**support/tracker.php?aid=918301<http://sourceforge.net/support/tracker.php?aid=918301>
>
> --
> k_satoda
>
[Attachment #5 (text/html)]
Hi Kazutoshi,<div>ok about reopening, in fact there are other tricks we can \
do.</div><div><br></div><div>For information I just tested text editors with a big \
xml file of 220MB, 3.3 million lines but no very long lines.</div>
<div><br></div><div>For the test I opened the file and moved to the end of the file \
(that's what takes a lot of time)</div><div><br></div><div>Surprisingly, the \
fastest, by far was jEdit :</div><div><br></div><div>here are my results and \
observations.</div>
<div><br></div><div>jEdit took 2.9 seconds using the trick I untroduced a few months \
ago : syntax is not aware of the context. This means that if the xml file starts with \
<!-- then end of the buffer will not be highlighted as a comment. </div>
<div>This lead to a possibly wrong syntax highlight but is lightning \
fast</div><div><br></div><div>Emacs took 7 seconds. That's really good too, and \
it seems they use the same trick as me, if the buffer starts with a comment, the end \
of the buffer is not highlighted with a comment. They have a feature activated that I \
had not : softwrap</div>
<div><br></div><div>sciTE took 13 seconds, and used context sensitive syntax, \
that's very fast. But if you change the beginning of the file then go again to \
the end, it will take 13 seconds again ...</div><div><br></div>
<div>UltraEdit took 18 seconds, and was not aware of the \
context</div><div><br></div><div>Vim took 53 seconds and it seems it was not aware of \
the context, that's strange it is so slow.</div><div><br></div><div>Notepad++ was \
the worse, after 2 minutes he was still working so I gave up.</div>
<div><br></div><div><br></div><div>My other ideas about jEit and big files is first \
an option to remember the choice (to not popup the windows about big files \
everytime)</div><div>Deactivate soft wrap since it is slow on big files</div>
<div>Deactivate syntax highlight for a single line if the line is too long. I think \
it is better than no syntax highlight at \
all.</div><div><br></div><div>Matthieu<br><br><div class="gmail_quote">2011/12/9 \
Kazutoshi Satoda <span dir="ltr"><<a \
href="mailto:k_satoda@f2.dion.ne.jp">k_satoda@f2.dion.ne.jp</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">Hi tvojeho, Thank you for the clarifying post.<div \
class="im"><br> <br>
tvojeho wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Yes, the discussion strayed off the original topic when I \
asked about<br> the large buffer handling.<br>
</blockquote>
<br></div>
FYI, I remembered the following advice as applying to this case.<br>
"No Conversations in the Bug Tracker"<br>
<a href="http://www.producingoss.com/en/bug-tracker-usage.html" \
target="_blank">http://www.producingoss.com/<u></u>en/bug-tracker-usage.html</a><div \
class="im"><br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> The logic behind that was that I had a large file to work \
with, was<br> experiencing the long loading with softwrap on, so when I fired up<br>
jEdit, went to make a coffee and came back expecting the file<br>
loaded - only to encounter the large file dialog - I tried to find out<br>
how to switch the dialog off, unsuccessfully.<br>
<br>
<br>
The open topic discussing poor performance with large files seemed<br>
like the place to ask. In the past,<br>
I have had e-mails bounced back when sending to jedit-users (I<br>
subscribed to the list today, I didn't know it was necessary before),<br>
so I tacked my question to an open ticket.<br>
<br>
I also think that the original ticket should not be closed, only my<br>
side problem was resolved.<br>
</blockquote>
<br></div>
Now the feature request #918301 has been reopend.<br>
<a href="http://sourceforge.net/support/tracker.php?aid=918301" \
target="_blank">http://sourceforge.net/<u></u>support/tracker.php?aid=918301</a><span \
class="HOEnZb"><font color="#888888"><br> <br>
-- <br>
k_satoda<br>
</font></span></blockquote></div><br></div>
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
--
-----------------------------------------------
jEdit Users' List
jEdit-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic