bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug swing/24152] New: major performance problem in JTextArea (TextModel


From: hendrich at informatik dot uni-hamburg dot de
Subject: [Bug swing/24152] New: major performance problem in JTextArea (TextModel?)
Date: 30 Sep 2005 19:49:41 -0000

The current implementation of JTextArea (or possibly the underlying TextModel,
perhaps even a bug in pango) makes it impossible to display and edit texts
with more than a few hundred characters. The attached testcase demonstrates
that current cp cvs code uses algorithm(s) of at least O(N*N), while the
reference implementatin seems to behave like O(ln N) at most.

Users will rightly expect to load and edit texts with a least a few thousand 
lines without major performance problems. Actually, I originally suspected
a complete deadlock in classpath for texts longer than a few hundred lines,
but the testcase shows that things only get (real) ssllooww. 

---

Run the attached testcase and specify the number of lines-of-text as the
first argument. The program does the following:

* first, create a JTextArea inside a JScrollPane inside a JFrame
* second, create a random text with the specified number of lines
* third, call setText() with the random text on the JTextArea
* fourth, pack the JFrame
* five, enter a loop that requests some JFrame resizing operations

The timing for all operations are measured via System.currentTimeMillis().
First, as a reference some performance numbers for JDK 1.5.0 (SuSE linux x86,
Athlon 2600+):

JDK 1.5.0  nlines  create  load-text     pack  resize   [msecs]

java PRuuu 20         143         71       47       1
java PRuuu 200        133         98       49       1
java PRuuu 2000       140        445       50       1
java PRuuu 20000      149       1350       52       1


And here the disappointing numbers from classpath (CVS HEAD 2005.09.30). 
Note that first-time initializiation is only four times slower on jamvm 
despite running interpreted (good!), but there seems at least an O(n^2) 
algorithm somewhere:

jamvm 1.3.2 with classpath cvs HEAD 2005.09.30 (-x200m -ms50m -verbose:gc)

jamvm+cp   nlines  create  load-text     pack  resize   [msecs]

jamvm PRuuu 20        589          5      117       80
jamvm PRuuu 40        582          6      426      275
jamvm PRuuu 80        581         10     1404     1100
jamvm PRuuu 160       584         18     5736     5000
jamvm PRuuu 320       583         35    23898    18250
...
jamvm PRuuu 2000      591        228   xxxxxx   xxxxxx  (canceled)
jamvm PRuuu 20000     594       2384 xxxxxxxx xxxxxxxx  (canceled)


Also, note that the JScrollPane is not working at all :-(


A stacktrace from gdb with jamvm stuck somewhere in the pack() call
shows the following:
(gdb) where
#0  0x40031e56 in __pthread_alt_unlock () from /lib/libpthread.so.0
#1  0x4002ebff in pthread_mutex_unlock () from /lib/libpthread.so.0
#2  0x40123965 in malloc () from /lib/libc.so.6
#3  0x4d61be22 in IA__g_malloc (n_bytes=1075709472) at gmem.c:137
#4  0x4d5a8aaa in new_type_link () at fribidi.c:77
#5  0x4d5a8b40 in run_length_encode_types (char_type=0x8528718, type_len=103)
    at fribidi.c:119
#6  0x4d5a8fb1 in fribidi_analyse_string (str=0x85274d0, len=103, 
    pbase_dir=0xbffff250, ptype_rl_list=0x1, 
    pmax_level=0x1 <Address 0x1 out of bounds>) at fribidi.c:533
#7  0x4d5a9a40 in pango_log2vis_get_embedding_levels (str=0x85274d0, 
    len=1075709488, pbase_dir=0x1, 
    embedding_level_list=0x8527678 "|\006\036@|address@hidden") at 
fribidi.c:1034
---Type <return> to continue, or q <return> to quit---
#8  0x4d5971fe in itemize_state_init (state=0xbffff2e0, context=0x1, 
    text=0x1 <Address 0x1 out of bounds>, base_dir=PANGO_DIRECTION_LTR, 
    start_index=24666, length=103, attrs=0x834ac38, cached_iter=0x83dc3d0, 
    desc=0x0) at pango-context.c:664
#9  0x4d597ed7 in pango_itemize_with_base_dir (context=0x401e0630, 
    base_dir=PANGO_DIRECTION_LTR, 
    text=0xbffff2e0 "address@hidden", start_index=1, 
    length=1, attrs=0x834ac38, cached_iter=0x83dc3d0) at pango-context.c:1183
#10 0x4d59f208 in pango_layout_check_lines (layout=0x82dd438)
    at pango-layout.c:3211
#11 0x4d59d715 in pango_layout_get_extents_internal (layout=0x82dd438, 
    ink_rect=0x0, logical_rect=0xbffff50c, line_extents=0x0)
    at pango-layout.c:2005
---Type <return> to continue, or q <return> to quit---
#12 0x4d59da58 in pango_layout_get_extents (layout=0x1, ink_rect=0x0, 
    logical_rect=0xbffff50c) at pango-layout.c:2151
#13 0x4d0cac49 in Java_gnu_java_awt_peer_gtk_GdkFontPeer_getTextMetrics (
    env=0x8061794, java_font=0x1, str=0x41fd9610, java_metrics=0x41ff4f68)
    at gnu_java_awt_peer_gtk_GdkFontPeer.c:301
#14 0x0805d875 in callJNIMethod (env=0x8061794, class=0x0, 
    sig=0x829c798 "(Ljava/lang/String;[D)V", ret_type=0, ostack=0x8083180, 
    f=0x4d0cabb0 "U\211åWVSè\232¬ÿÿ\201Ã9ù\001", args=3) at dll_md.c:64
#15 0x0804e931 in callJNIWrapper (class=0x0, mb=0x82b167c, ostack=0x1)
    at dll.c:325
#16 0x08051856 in executeJava () at interp.c:2236
#17 0x0804f557 in executeMethodVaList (ob=Variable "ob" is not available.
) at execute.c:66
#18 0x0804f5f9 in executeMethodArgs (ob=0x1, class=0x1, mb=0x1) at execute.c:38
---Type <return> to continue, or q <return> to quit---
#19 0x08052a97 in main (argc=6, argv=0xbffff774) at jam.c:327

-- 
           Summary: major performance problem in JTextArea (TextModel?)
           Product: classpath
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: swing
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hendrich at informatik dot uni-hamburg dot de
                CC: bug-classpath at gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24152




reply via email to

[Prev in Thread] Current Thread [Next in Thread]