Opened 10 years ago

Closed 10 years ago

#558 closed enhancement (fixed)

Printing long strings in the IDE is veeeerrrry sssllloooowwww

Reported by: rongarret Owned by: gb
Priority: minor Milestone:
Component: IDE Version: trunk
Keywords: Cc:

Description

? (time (print (make-string 10000)))
""
(PRINT (MAKE-STRING 10000)) took 11,157,608 microseconds (11.157608 seconds) to run 
                    with 2 available CPU cores.
During that period, 10,291,164 microseconds (10.291164 seconds) were spent in user mode
                    868,038 microseconds (0.868038 seconds) were spent in system mode
70,577 microseconds (0.070577 seconds) was spent in GC.
 97,616 bytes of memory allocated.
 120 minor page faults, 12,281 major page faults, 0 swaps.
""

Note that the above was run with string highlighting disabled. When it's enabled, things get even slower. (See ticket #540.)

It would also be nice (and would be a resolution of this ticket as far as I'm concerned) to have something like *print-length* that applied to strings. I'm doing some database work that involves very long strings (megabytes) and it would be very nice not to have to manually kill the printing process whenever I accidentally print one of these monsters.

I'm calling this a "minor enhancement" because I can work around it myself by defining a print-object method on strings.

Change History (5)

comment:1 in reply to: ↑ description Changed 10 years ago by rongarret

Replying to rongarret:

It would also be nice (and would be a resolution of this ticket as far as I'm concerned) to have something like *print-length* that applied to strings.

Well, whaddya know:

? (setf *print-string-length* 100)
100
? (make-string 1000 :initial-element #\.)
#<SIMPLE-STRING 1000 .....................>

I'm going to leave this ticket open though because it still seems to me that strings out to print out faster than a millisecond per character on a 2GHz machine.

comment:2 Changed 10 years ago by gb

  • Owner set to gb

The buffer that LISTENER-OUTPUT-STREAMs use is way too small (100 characters; see the DEFPARAMETER of $LISTENER-FLUSH-LIMIT in ccl:cocoa-ide;cocoa-listener.lisp) to handle this much output reasonably; every time that stream buffer fills, the event thread has to be interrupted and persuaded to copy the string into the listener buffer and prepare for redisplay; the event thread's often busy doing redisplay in this scenario, and it's not surprising that it takes a while to write 10K characters (even if they're all #\NULs).

There's likely more that can be done to speed this up on the event-thread side, but just changing that parameter to 2K or 4K (and recompiling; the code may not like the "parameter" to change at runtime) removes a lot of the synchronization overhead and speeds this up pretty dramatically.

(FWIW, printing a string full of #\NULs seems to be slower than printing a string full of visible characters.)

comment:3 follow-up: Changed 10 years ago by rongarret

just changing that parameter to 2K or 4K (and recompiling) ... speeds this up pretty dramatically.

I tried this. It works like a charm. Thanks Gary!

comment:4 in reply to: ↑ 3 Changed 10 years ago by rongarret

Replying to rongarret:

just changing that parameter to 2K or 4K (and recompiling) ... speeds this up pretty dramatically.

I tried this. It works like a charm. Thanks Gary!

Turns out this also fixes ticket #540. Woohoo!

comment:5 Changed 10 years ago by gb

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in r12423.

Note: See TracTickets for help on using tickets.