unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* indent-region for long Java strings very slow
@ 2006-10-26 14:15 giethomas
  2006-10-26 15:06 ` David Hansen
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: giethomas @ 2006-10-26 14:15 UTC (permalink / raw)


When I build a very long Java String with lots of components (... + ...
+ ... +), spread out over many lines (each terminated by a newline),
indent-region gets very, very slow.

Anybody any idea why and how to avoid this?

Thanks

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: indent-region for long Java strings very slow
  2006-10-26 14:15 indent-region for long Java strings very slow giethomas
@ 2006-10-26 15:06 ` David Hansen
       [not found] ` <mailman.268.1161875351.27805.help-gnu-emacs@gnu.org>
  2006-10-26 23:12 ` Ilya Zakharevich
  2 siblings, 0 replies; 8+ messages in thread
From: David Hansen @ 2006-10-26 15:06 UTC (permalink / raw)


On 26 Oct 2006 07:15:17 -0700 "giethomas@gmail.com" <giethomas@gmail.com> wrote:

> When I build a very long Java String with lots of components (... + ...
> + ... +), spread out over many lines (each terminated by a newline),
> indent-region gets very, very slow.

Not emacs related:  AFAIK javac creates a new StringBuffer
object for *each* `+'.  So if you don't want your program to
be unnecessarily slow do something like

String foo = (new StringBuffer ()).append (...)
  .append (...)
  .append (...)
  // ...
  .toString ();

David

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: indent-region for long Java strings very slow
       [not found] ` <mailman.268.1161875351.27805.help-gnu-emacs@gnu.org>
@ 2006-10-26 17:43   ` Chris McMahan
  2006-10-26 19:21     ` David Hansen
  2006-10-27  6:56     ` giethomas
  0 siblings, 2 replies; 8+ messages in thread
From: Chris McMahan @ 2006-10-26 17:43 UTC (permalink / raw)


I think the issue is not the running time of the program, but the time
it takes emacs to parse the string sequence when indenting the java
source code. In that case, it is an emacs issue.

I would agree, however, with David's assessment that it's extremely
inefficient to build a string with the series of concatenated strings,
as Java does construct a separate string object for each
concatenation. StringBuffer, as suggested, would be the way to go
here.

- Chris

David Hansen <david.hansen@gmx.net> writes:

> On 26 Oct 2006 07:15:17 -0700 "giethomas@gmail.com" <giethomas@gmail.com> wrote:
>
>> When I build a very long Java String with lots of components (... + ...
>> + ... +), spread out over many lines (each terminated by a newline),
>> indent-region gets very, very slow.
>
> Not emacs related:  AFAIK javac creates a new StringBuffer
> object for *each* `+'.  So if you don't want your program to
> be unnecessarily slow do something like
>
> String foo = (new StringBuffer ()).append (...)
>   .append (...)
>   .append (...)
>   // ...
>   .toString ();
>
> David
>
>
>

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: indent-region for long Java strings very slow
  2006-10-26 17:43   ` Chris McMahan
@ 2006-10-26 19:21     ` David Hansen
  2006-10-27  6:56     ` giethomas
  1 sibling, 0 replies; 8+ messages in thread
From: David Hansen @ 2006-10-26 19:21 UTC (permalink / raw)


On Thu, 26 Oct 2006 13:43:16 -0400 Chris McMahan wrote:

> I think the issue is not the running time of the program, but the time
> it takes emacs to parse the string sequence when indenting the java
> source code. In that case, it is an emacs issue.

That's what i wanted to say with the "Not emacs related".
Sorry for not being clear here.

David

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: indent-region for long Java strings very slow
  2006-10-26 14:15 indent-region for long Java strings very slow giethomas
  2006-10-26 15:06 ` David Hansen
       [not found] ` <mailman.268.1161875351.27805.help-gnu-emacs@gnu.org>
@ 2006-10-26 23:12 ` Ilya Zakharevich
  2006-11-18 20:31   ` David Combs
  2 siblings, 1 reply; 8+ messages in thread
From: Ilya Zakharevich @ 2006-10-26 23:12 UTC (permalink / raw)


[A complimentary Cc of this posting was sent to
giethomas@gmail.com
<giethomas@gmail.com>], who wrote in article <1161872117.135227.178220@i42g2000cwa.googlegroups.com>:
> When I build a very long Java String with lots of components (... + ...
> + ... +), spread out over many lines (each terminated by a newline),
> indent-region gets very, very slow.
> 
> Anybody any idea why and how to avoid this?

I suspect that this indicates c-mode being too dumb to use linear-time
indent algorithm.  20 years ago it was acceptable to have
quadratic-time indent logic; one could not do better, since
parse-partial-sexp was not designed well enough.  But I added
necessary hooks to parse-partial-sexp (more than?) 10 years ago.

Nowadays all the decent modes should have linear-time logic for
indent.  It looks like c-mode is not decent enough...

Puzzled,
Ilya

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: indent-region for long Java strings very slow
  2006-10-26 17:43   ` Chris McMahan
  2006-10-26 19:21     ` David Hansen
@ 2006-10-27  6:56     ` giethomas
  1 sibling, 0 replies; 8+ messages in thread
From: giethomas @ 2006-10-27  6:56 UTC (permalink / raw)


I agree about the inefficiency of building a string with a series of
concatenated strings. but this leaves the emacs issue of parsing the
string sequence when indenting the java source code.

The problem gets worse and worse with longer source files, even though
I only run indent-region.

On Oct 26, 7:43 pm, Chris McMahan <first_initiallastn...@one.dot.net>
wrote:
> I think the issue is not the running time of the program, but the time
> it takes emacs to parse the string sequence when indenting thejava
> source code. In that case, it is an emacs issue.
>
> I would agree, however, with David's assessment that it's extremely
> inefficient to build a string with the series of concatenatedstrings,
> asJavadoes construct a separate string object for each
> concatenation. StringBuffer, as suggested, would be the way to go
> here.
>
> - Chris
>
>
>
> David Hansen <david.han...@gmx.net> writes:
> > On 26 Oct 2006 07:15:17 -0700 "gietho...@gmail.com" <gietho...@gmail.com> wrote:
>
> >> When I build averylongJavaString with lots of components (... + ...
> >> + ... +), spread out over many lines (each terminated by a newline),
> >>indent-regiongetsvery,veryslow.
>
> > Not emacs related:  AFAIK javac creates a new StringBuffer
> > object for *each* `+'.  So if you don't want your program to
> > be unnecessarilyslowdo something like
>
> > String foo = (new StringBuffer ()).append (...)
> >   .append (...)
> >   .append (...)
> >   // ...
> >   .toString ();
>
> > David--
>      (.   .)
>   =ooO=(_)=Ooo=====================================
>   Chris McMahan | first_initiallastn...@one.dot.net
>   =================================================

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: indent-region for long Java strings very slow
  2006-10-26 23:12 ` Ilya Zakharevich
@ 2006-11-18 20:31   ` David Combs
  2006-11-19  7:55     ` Ilya Zakharevich
  0 siblings, 1 reply; 8+ messages in thread
From: David Combs @ 2006-11-18 20:31 UTC (permalink / raw)


In article <ehrfdf$1lhg$1@agate.berkeley.edu>,
Ilya Zakharevich  <nospam-abuse@ilyaz.org> wrote:
>[A complimentary Cc of this posting was sent to
>giethomas@gmail.com
><giethomas@gmail.com>], who wrote in article <1161872117.135227.178220@i42g2000cwa.googlegroups.com>:
>> When I build a very long Java String with lots of components (... + ...
>> + ... +), spread out over many lines (each terminated by a newline),
>> indent-region gets very, very slow.
>> 
>> Anybody any idea why and how to avoid this?
>
>I suspect that this indicates c-mode being too dumb to use linear-time
>indent algorithm.  20 years ago it was acceptable to have
>quadratic-time indent logic; one could not do better, since
>parse-partial-sexp was not designed well enough.  But I added
>necessary hooks to parse-partial-sexp (more than?) 10 years ago.
>
>Nowadays all the decent modes should have linear-time logic for
>indent.  It looks like c-mode is not decent enough...
>
>Puzzled,
>Ilya

FOI: are you perhaps thinking of fixing it?


Thanks

David

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: indent-region for long Java strings very slow
  2006-11-18 20:31   ` David Combs
@ 2006-11-19  7:55     ` Ilya Zakharevich
  0 siblings, 0 replies; 8+ messages in thread
From: Ilya Zakharevich @ 2006-11-19  7:55 UTC (permalink / raw)


[A complimentary Cc of this posting was sent to
David Combs
<dkcombs@panix.com>], who wrote in article <ejnqii$jjp$1@reader2.panix.com>:
> >Nowadays all the decent modes should have linear-time logic for
> >indent.  It looks like c-mode is not decent enough...

> FOI: are you perhaps thinking of fixing it?

I fixed the mode(s) I care about the same moment I made
parse-partial-sexp smart enough to support linear-time logic.  If you
are interested in fixing other modes, I may try to find this 10-years
old patch.  Or just look how cperl-emacs-can-parse is used in
cperl-mode.el...

Hope this helps,
Ilya

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2006-11-19  7:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-26 14:15 indent-region for long Java strings very slow giethomas
2006-10-26 15:06 ` David Hansen
     [not found] ` <mailman.268.1161875351.27805.help-gnu-emacs@gnu.org>
2006-10-26 17:43   ` Chris McMahan
2006-10-26 19:21     ` David Hansen
2006-10-27  6:56     ` giethomas
2006-10-26 23:12 ` Ilya Zakharevich
2006-11-18 20:31   ` David Combs
2006-11-19  7:55     ` Ilya Zakharevich

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).