From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Han-Wen Nienhuys Newsgroups: gmane.lisp.guile.devel Subject: expensive backtraces. Date: Sat, 15 Feb 2003 19:41:21 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <15950.35281.669014.657068@blauw.xs4all.nl> Reply-To: hanwen@cs.uu.nl NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1045334379 13463 80.91.224.249 (15 Feb 2003 18:39:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 15 Feb 2003 18:39:39 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18k7Dt-0003V0-00 for ; Sat, 15 Feb 2003 19:39:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18k7Fg-0005Pj-03 for guile-devel@m.gmane.org; Sat, 15 Feb 2003 13:41:28 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18k7FG-0005GY-00 for guile-devel@gnu.org; Sat, 15 Feb 2003 13:41:02 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18k7FB-0005AN-00 for guile-devel@gnu.org; Sat, 15 Feb 2003 13:40:58 -0500 Original-Received: from smtpzilla5.xs4all.nl ([194.109.127.141]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18k7Ef-0004m3-00 for guile-devel@gnu.org; Sat, 15 Feb 2003 13:40:25 -0500 Original-Received: from blauw.xs4all.nl (blauw.xs4all.nl [213.84.26.127]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id h1FIeN4L013629 for ; Sat, 15 Feb 2003 19:40:23 +0100 (CET) Original-To: guile-devel@gnu.org X-Mailer: VM 7.05 under Emacs 21.2.1 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1938 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1938 Hi there, On some occasions, printing a backtrace from GUILE takes an extraordinary amount of time. Example blauw:~/usr/src/lilypond$ time lilypond ki.ly lstat(/home/hanwen/bin/usr) failed ... /home/hanwen/bin/usr: Onbekend bestand of map GNU LilyPond 1.7.12 Now processing: `ki.ly' Parsing...Backtrace: In ki.ly: 1: 0* [sequential-music-to-chord-exceptions #] In unknown file: ?: 1 (letrec (# #) (let* # #)) In /home/hanwen/usr/src/lilypond/scm/double-plus-new-chord-name.scm: 337: 2 (let* ((elts #) (alist #)) (filter-list (lambda # #) alist)) 339: 3* [filter-list # ... 339: 4* (ly:get-music-property seq (quote elements)) /home/hanwen/usr/src/lilypond/scm/double-plus-new-chord-name.scm:339:39: In expression (ly:get-music-property seq (quote elements)): /home/hanwen/usr/src/lilypond/scm/double-plus-new-chord-name.scm:339:39: Unbound variable: ly:get-music-property real 0m9.369s user 0m9.200s sys 0m0.080s between printing 1: 0* and the rest, is approximately 8 seconds. I think this is exorbitant on a 400mhz machine. When tracing this with GDB, it seems that a lot of memory is filled and GC-ed again for printing enormous structures, which are later folded into '#' marks again. Now processing: `ki.ly' Parsing...Backtrace: In ki.ly: 1: 0* Program received signal SIGINT, Interrupt. 0x40049023 in scm_i_sweep_card (p=0x40a76ab0, free_list=0xbfffdaf8, seg=0x40a76aa0) at gc-card.c:104 warning: Source file is more recent than executable. (gdb) fin Lots of "finish" st_resize_port (pt=0x83393c0, new_size=18960) at strports.c:109 warning: Source file is more recent than executable. Value returned is $4 = (struct scm_unused_struct *) 0x4041c7f8 (gdb) 0x4007b16a in st_flush (port=0x83bb960) at strports.c:136 (gdb) p pt->write_buf $5 = ( unsigned char *) 0x83b6ff0 "[sequential-music-to-chord-exceptions #\nelements = (#write_buf_size $6 = 18960 (gdb) p pt->write_buf[0]@18960 $7 = "[sequential-music-to-chord-exceptions #\nelements = (#write_buf+ 100 [more enormously long string] Other than trimming my "print_smob()" routines, does anyone see a solution to this problem from the GUILE side? Ideally, the printing of a large structure should be interrupted once the length of its output exceeds a certain size. It seems that right now, first the entire object is printed (taking a lot of time), and then all that printout is replaced by "#" if too large. In the short-run, it would be nice to mention something about this in the manual; I'm not sure about the correct wording though. Maybe something like: One of the uses of the print-method is in printing expressions during stack traces. Therefore, make sure that this method prints only a limited amount of data. Excessively long print out will be discarded, and will lead to long delays during debugging. -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel