unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jörg Walter" <jwalt@garni.ch>
To: 12463@debbugs.gnu.org
Subject: bug#12463: 24.2; pos-visible-in-window-p gets slower over time
Date: Tue, 18 Sep 2012 18:18:56 +0200	[thread overview]
Message-ID: <4023344.MyoQPQRfcJ@queen> (raw)
In-Reply-To: <87d31jcqce.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

Op den Dingsdag, de 18. September 2012 Klock 23:17:53 hett Chong Yidong 
schreven:
> Eli Zaretskii <eliz@gnu.org> writes:
> > Can anyone else reproduce this?
> 
> I can reproduce this.  On bisecting, the problem first shows up with
> 
>   revno: 104186
>   fixes bug: http://debbugs.gnu.org/8640
>   committer: Juanma Barranquero <lekktu@gmail.com>
>   branch nick: trunk
>   timestamp: Tue 2011-05-10 12:31:33 +0200
>   message:
>   src/image.c (Finit_image_library): Return t for built-in image types.
> 
> A quick glance at the diff of this revision does not reveal immediately
> why it causes the problem, though.

I have no idea why that revision triggers the bug either, but here is a patch 
that fixes the problem. I have no idea if it matches your quality standards, 
but I think it is clean enough. I've reused and adapted some code already 
present for Win32 (which is the reason they don't suffer the same problem).

The linked list `image_types' grows without bounds because 
CHECK_LIB_AVAILABLE/define_image_type never checked if the given image type is 
already in `image_types'. My lisp code triggered tons of `Finit_image_library' 
calls. Since the list is searched linearly at some point, that explains the 
run-time impact.

I have no idea what was originally supposed to ensure `image_types' doesn't 
include duplicate entries, so the patch may be way off... hope someone actually 
knows what is suppsed to go on there.

-- 
CU
	Jörg

[-- Attachment #2: emacs-image-bug.patch --]
[-- Type: text/x-patch, Size: 1421 bytes --]

--- image.c	2012-09-18 18:10:21.952695267 +0200
+++ image.c.new	2012-09-18 18:09:18.173692841 +0200
@@ -575,12 +575,11 @@
 static void x_emboss (struct frame *, struct image *);
 static int x_build_heuristic_mask (struct frame *, struct image *,
 				   Lisp_Object);
-#ifdef HAVE_NTGUI
+
+static Lisp_Object loaded_image_types;
+
 #define CACHE_IMAGE_TYPE(type, status) \
-  do { Vlibrary_cache = Fcons (Fcons (type, status), Vlibrary_cache); } while (0)
-#else
-#define CACHE_IMAGE_TYPE(type, status)
-#endif
+  do { loaded_image_types = Fcons (Fcons (type, status), loaded_image_types); } while (0)
 
 #define ADD_IMAGE_TYPE(type) \
   do { Vimage_types = Fcons (type, Vimage_types); } while (0)
@@ -8743,12 +8742,10 @@
 of `dynamic-library-alist', which see).  */)
   (Lisp_Object type, Lisp_Object libraries)
 {
-#ifdef HAVE_NTGUI
   /* Don't try to reload the library.  */
-  Lisp_Object tested = Fassq (type, Vlibrary_cache);
+  Lisp_Object tested = Fassq (type, loaded_image_types);
   if (CONSP (tested))
     return XCDR (tested);
-#endif
 
   /* Types pbm and xbm are built-in and always available.  */
   if (EQ (type, Qpbm) || EQ (type, Qxbm))
@@ -8828,6 +8825,9 @@
 non-numeric, there is no explicit limit on the size of images.  */);
   Vmax_image_size = make_float (MAX_IMAGE_SIZE);
 
+  loaded_image_types = Qnil;
+  staticpro(&loaded_image_types);
+
   DEFSYM (Qpbm, "pbm");
   ADD_IMAGE_TYPE (Qpbm);
 

  reply	other threads:[~2012-09-18 16:18 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-17 23:51 bug#12463: 24.2; pos-visible-in-window-p gets slower over time Jörg Walter
2012-09-18  7:46 ` Eli Zaretskii
2012-09-18  9:46   ` Jörg Walter
2012-09-18 10:23     ` Eli Zaretskii
2012-09-18 15:05     ` Matt Lundin
2012-09-18 16:24       ` Eli Zaretskii
2012-09-18 15:17   ` Chong Yidong
2012-09-18 16:18     ` Jörg Walter [this message]
2012-09-20 23:22       ` Juanma Barranquero
2012-09-21  3:52         ` Chong Yidong
2012-09-21  5:42           ` Chong Yidong
2012-09-21  7:34             ` Eli Zaretskii
2012-09-21  9:24               ` Chong Yidong
2012-09-21 10:47                 ` Juanma Barranquero
2012-09-21 12:33                   ` Eli Zaretskii
2012-09-21 16:38                     ` Stefan Monnier
2012-09-21 16:58                       ` Eli Zaretskii
2012-09-21 20:34                         ` Stefan Monnier
2012-09-22  6:58                           ` Eli Zaretskii
2012-09-22 20:20                             ` Stefan Monnier
2012-09-22 20:31                               ` Juanma Barranquero
2012-09-23  9:17                                 ` Chong Yidong
2012-09-23  3:50                               ` Eli Zaretskii
2012-09-21  9:10             ` Juanma Barranquero
2012-09-21 10:01               ` Chong Yidong
2012-09-21 17:03                 ` Eli Zaretskii
2012-09-21 17:07                   ` Juanma Barranquero
2012-09-21 17:45                     ` Eli Zaretskii
2012-09-22  1:23                       ` Chong Yidong
2012-09-22  8:36                         ` Eli Zaretskii
2012-09-22 11:05                           ` Chong Yidong
2012-09-22 11:18                             ` Eli Zaretskii
2012-09-22 14:14                               ` Chong Yidong
2012-09-22 14:25                                 ` Eli Zaretskii
2012-09-22 19:20                                 ` Juanma Barranquero
2012-09-22 19:46                                   ` Eli Zaretskii
2012-09-22 19:53                                     ` Juanma Barranquero
2012-09-23  3:48                                       ` Eli Zaretskii
2012-09-21  6:58           ` Eli Zaretskii
2012-09-21  8:36           ` Juanma Barranquero
2012-09-21  9:11             ` Chong Yidong
2012-09-21  9:17               ` Juanma Barranquero
2012-09-18 16:19     ` Eli Zaretskii
2012-09-18 16:26       ` Jörg Walter
2012-09-18 17:19         ` Eli Zaretskii
2012-09-18 17:31           ` Juanma Barranquero
2012-09-18 20:00             ` Eli Zaretskii
2012-09-19  2:31               ` Juanma Barranquero
2012-09-19  2:57                 ` Eli Zaretskii
2012-09-19  3:03                   ` Juanma Barranquero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4023344.MyoQPQRfcJ@queen \
    --to=jwalt@garni.ch \
    --cc=12463@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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