From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MIYOSHI Masanori Newsgroups: gmane.emacs.devel Subject: Emacs allocates unnecessary memory during scrolling Date: Mon, 16 Oct 2006 23:23:06 +0900 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1161008685 9864 80.91.229.2 (16 Oct 2006 14:24:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 16 Oct 2006 14:24:45 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 16 16:24:37 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GZTO6-0002QB-30 for ged-emacs-devel@m.gmane.org; Mon, 16 Oct 2006 16:24:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GZTO6-0006PG-BF for ged-emacs-devel@m.gmane.org; Mon, 16 Oct 2006 10:24:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GZTNf-0006He-PV for emacs-devel@gnu.org; Mon, 16 Oct 2006 10:23:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GZTNd-0006Et-VW for emacs-devel@gnu.org; Mon, 16 Oct 2006 10:23:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GZTNd-0006Ed-KW for emacs-devel@gnu.org; Mon, 16 Oct 2006 10:23:49 -0400 Original-Received: from [58.93.247.202] (helo=mvs2.plala.or.jp) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GZTWl-00071Y-DM for emacs-devel@gnu.org; Mon, 16 Oct 2006 10:33:15 -0400 Original-Received: from msc1.plala.or.jp ([172.23.8.24]) by mvs2.plala.or.jp with ESMTP id <20061016142313.GRAJ12915.mvs2.plala.or.jp@msc1.plala.or.jp> for ; Mon, 16 Oct 2006 23:23:13 +0900 Original-Received: from malebolgia ([220.221.53.58]) by msc1.plala.or.jp with ESMTP id <20061016142313.BOY29163.msc1.plala.or.jp@malebolgia> for ; Mon, 16 Oct 2006 23:23:13 +0900 Original-To: emacs-devel@gnu.org X-Face: ,IaMiin=o[9Fn@w^6PYglEEkK]5c`b3Jb&GIm+"D8>+~.^'Ua)}-+1; N:u{iz{mhvm2@pPf@\r3ud25~["?M '}RF!O)TLU;ymE2{[>Yq,Qz|[6B:qZdL`1)J~? User-Agent: Gnus/5.110006 (No Gnus v0.6) Meadow-3.00-dev (KIKU) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:60791 Archived-At: Emacs 22 on Windows (and probably on other platforms) allocates unnecessary memory during scrolling. The following opearaion reproduces the problem. o emacs -q o Evaluate (setq scroll-conservatively 10) on the scratch buffer. o Type `C-h' to view the HELLO file. o Type `C-n' on to scroll the window. o Emacs allocates unnecessary memory during scrolling. Large files which contains multibyte characters should be better for reproduction. Findings are: This changes seems to have revealed the problem. > 2006-09-06 Kim F. Storm > > * xdisp.c (pos_visible_p): Remove exact_mode_line_heights_p arg; > so calculate heights even when pos-visible-in-window-p is called > with partially = t. Don't overshoot last_visible_y in move_it_to. > Return row height and row number in new rowh and vpos args. In the following call sequences, it->w->ncols_scale_factor is incremented a number of times. In xdisp.c: pos_visible_p() -> display_mode_line() -> display_mode_element() ;; case MODE_LINE_DISPLAY: -> display_string() -> PRODUCE_GLYPHS() -> x_produce_glyphs() ;; RIF -> append_glyph() ;; it->glyph_row->used[area]++ -> IT_EXPAND_MATRIX_WIDTH() ;; it->w->ncols_scale_factor++ In consequence, required_matrix_width() in dispnew.c returns a large number. And adjust_glyph_matrix() in dispnew.c allocates unnecessary large memory for glyphs. YAMAMOTO Mitsuharu san says: In xdisp.c: > static int > display_mode_line (w, face_id, format) snip > { snip > init_iterator (&it, w, -1, -1, NULL, face_id); > prepare_desired_row (it.glyph_row); Before prepare_desired_row(), it.glyph_row->enabled_p happens not to be 0. This might be caused by the interruption of redisplay during scrolling. Appending the next code before prepare_desired_row() may fix the problem. > it.glyph_row->enabled_p = 0; But he doesn't know the place is appropriate or not. -- MIYOSHI Masanori