Windows: Emacs 24.1 binary size vs 24.2 binary size

Windows: Emacs 24.1 binary size vs 24.2 binary size

[Christoph Scholtes]

I just built the latest 24.2 release on Windows and I noticed a 
significant difference in the binary size of emacs.exe between version 
24.1 and 24.2. Was there any change that would explain the difference?

emacs.exe (24.1): 11,343,408 bytes
emacs.exe (24.2):  9,881,136 bytes

Both versions were compiled with gcc 4.6.2

Christoph

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Christoph Scholtes]

On 8/28/2012 8:20 PM, Christoph Scholtes wrote:
> I just built the latest 24.2 release on Windows and I noticed a
> significant difference in the binary size of emacs.exe between version
> 24.1 and 24.2. Was there any change that would explain the difference?
>
> emacs.exe (24.1): 11,343,408 bytes
> emacs.exe (24.2):  9,881,136 bytes
>
> Both versions were compiled with gcc 4.6.2

I'd like to have an answer just in case anybody else notices after I 
upload the release build. Any ideas?

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Eli Zaretskii]

> Date: Sat, 01 Sep 2012 08:21:14 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: Eli Zaretskii <eliz@gnu.org>
> 
> On 8/28/2012 8:20 PM, Christoph Scholtes wrote:
> > I just built the latest 24.2 release on Windows and I noticed a
> > significant difference in the binary size of emacs.exe between version
> > 24.1 and 24.2. Was there any change that would explain the difference?
> >
> > emacs.exe (24.1): 11,343,408 bytes
> > emacs.exe (24.2):  9,881,136 bytes
> >
> > Both versions were compiled with gcc 4.6.2
> 
> I'd like to have an answer just in case anybody else notices after I 
> upload the release build. Any ideas?

I don't have a stripped binary to compare with your numbers.  I do see
a similar decrease in the size of the un-stripped emacs.exe, but I
cannot find any explanation for that.  The size of temacs.exe is
almost identical between the 2 versions, which seems to point to Lisp,
or to data structures built by Emacs during loadup/dump process.
However, loadup.el saw no changes between the 2 versions, and
loaddefs.el is identical modulo time stamps of the files it records.
And I cannot spot anything pertinent, neither in src/ChangeLog nor in
lisp/ChangeLog.

So I have no idea what could explain the 1.6MB decrease in the exe
size.

The memory footprint of "emacs -Q" is 0.7MB _larger_ with Emacs 24.2
than it is with 24.1, FWIW.

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Christoph Scholtes]

On 9/1/2012 8:50 AM, Eli Zaretskii wrote:

> I don't have a stripped binary to compare with your numbers.  I do see
> a similar decrease in the size of the un-stripped emacs.exe, but I
> cannot find any explanation for that.  The size of temacs.exe is
> almost identical between the 2 versions, which seems to point to Lisp,
> or to data structures built by Emacs during loadup/dump process.
> However, loadup.el saw no changes between the 2 versions, and
> loaddefs.el is identical modulo time stamps of the files it records.
> And I cannot spot anything pertinent, neither in src/ChangeLog nor in
> lisp/ChangeLog.

Thanks. I will try Oscar's suggestion and bisect just to be sure.

Christoph

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Christoph]

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

On Sat, Sep 1, 2012 at 8:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>
> So I have no idea what could explain the 1.6MB decrease in the exe
> size.


Bisection via bootstraps lead to r108079 where the size decreases to 9,634
KB.


Backport fix for Bug#11989 from trunk.

* mouse.el (mouse-drag-track): Do not set the mark if the user
releases the mouse without selecting anything.


Bootstrapping r108078 yields emacs.exe with 11,062KB, bootstrapping r108079
yields 9,634KB. I did it multiple times to be sure.

Any ideas?

[-- Attachment #2: Type: text/html, Size: 943 bytes --]

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Eli Zaretskii]

> Date: Sun, 9 Sep 2012 20:42:06 -0600
> From: Christoph <cschol2112@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> Bisection via bootstraps lead to r108079 where the size decreases to 9,634
> KB.
> 
> 
> Backport fix for Bug#11989 from trunk.
> 
> * mouse.el (mouse-drag-track): Do not set the mark if the user
> releases the mouse without selecting anything.
> 
> 
> Bootstrapping r108078 yields emacs.exe with 11,062KB, bootstrapping r108079
> yields 9,634KB. I did it multiple times to be sure.
> 
> Any ideas?

None whatsoever.  This revision changes a few lines in a single
function, see the diffs below.  None of the changes should cause or
prevent loading of some other package, AFAICS.

IOW, it all sounds like some obscure bug triggered indirectly either
by previous versions or by the new version.  Beats me how, though.

One way to explore this further would be to dump the pure space in the
2 builds and compare them.  I don't know of any convenient method of
doing that.

In any case, I don't think you should delay the 24.2 binaries any
more.  I'm using 24.2 every day since the release, on 2 different
machines, and didn't see any problems.

Thanks.

=== modified file 'lisp/mouse.el'
--- lisp/mouse.el	2012-04-20 08:49:24 +0000
+++ lisp/mouse.el	2012-07-25 06:14:30 +0000
@@ -806,7 +806,7 @@ DO-MOUSE-DRAG-REGION-POST-PROCESS should
 	 ;; when setting point near the right fringe (but see below).
 	 (automatic-hscrolling-saved automatic-hscrolling)
 	 (automatic-hscrolling nil)
-	 event end end-point)
+	 moved-off-start event end end-point)
 
     (setq mouse-selection-click-count click-count)
     ;; In case the down click is in the middle of some intangible text,
@@ -841,6 +841,9 @@ DO-MOUSE-DRAG-REGION-POST-PROCESS should
 	    (redisplay))
 	  (setq end (event-end event)
 		end-point (posn-point end))
+	  ;; Note whether the mouse has left the starting position.
+	  (unless (eq end-point start-point)
+	    (setq moved-off-start t))
 	  (if (and (eq (posn-window end) start-window)
 		   (integer-or-marker-p end-point))
 	      (mouse--drag-set-mark-and-point start-point
@@ -881,11 +884,11 @@ DO-MOUSE-DRAG-REGION-POST-PROCESS should
 		   (let (deactivate-mark)
 		     (copy-region-as-kill (mark) (point)))))
 
-	  ;; If point hasn't moved, run the binding of the
-	  ;; terminating up-event.
-	  (if do-multi-click
-	      (goto-char start-point)
-	    (deactivate-mark))
+	  ;; Otherwise, run binding of terminating up-event.
+	  (cond
+	   (do-multi-click (goto-char start-point))
+	   (moved-off-start (deactivate-mark))
+	   (t (pop-mark)))
 	  (when (and (functionp fun)
 		     (= start-hscroll (window-hscroll start-window))
 		     ;; Don't run the up-event handler if the window

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Christoph]

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

On Sun, Sep 9, 2012 at 10:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> None whatsoever.  This revision changes a few lines in a single
> function, see the diffs below.  None of the changes should cause or
> prevent loading of some other package, AFAICS.
>
> IOW, it all sounds like some obscure bug triggered indirectly either
> by previous versions or by the new version.  Beats me how, though.
>
> One way to explore this further would be to dump the pure space in the
> 2 builds and compare them.  I don't know of any convenient method of
> doing that.


I will dig around some more as time permits.


> In any case, I don't think you should delay the 24.2 binaries any
> more.  I'm using 24.2 every day since the release, on 2 different
> machines, and didn't see any problems.


OK. I will upload the 24.2 tonight.

Thanks.

[-- Attachment #2: Type: text/html, Size: 1304 bytes --]

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Stefan Monnier]

>> So I have no idea what could explain the 1.6MB decrease in the exe
>> size.
> Bisection via bootstraps lead to r108079 where the size decreases to 9,634
> KB.
> Backport fix for Bug#11989 from trunk.
> * mouse.el (mouse-drag-track): Do not set the mark if the user
> releases the mouse without selecting anything.
> Bootstrapping r108078 yields emacs.exe with 11,062KB, bootstrapping r108079
> yields 9,634KB. I did it multiple times to be sure.
> Any ideas?

That sounds weird, indeed.  An explanation that comes to my mind
goes along the following lines:

   little change in code
   => slight change in some part of the dump process
   => memory allocation pattern at that point is different
   => some memory zone that used to be `free'able now can't be freed any
      more because some surviving object is now placed in that zone rather
      in some other zone.

IOW the actual live data is pretty much the same, but the larger binary
has a lot more memory that's "allocated from the OS but kept in some
free list".  How do the

   Pure-hashed: <FOO>
   Dumping under the name emacs
   <BAR> pure bytes used

compare between the two builds?


        Stefan

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Christoph]

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

On Mon, Sep 10, 2012 at 8:58 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> That sounds weird, indeed.  An explanation that comes to my mind
> goes along the following lines:
>
>    little change in code
>    => slight change in some part of the dump process
>    => memory allocation pattern at that point is different
>    => some memory zone that used to be `free'able now can't be freed any
>       more because some surviving object is now placed in that zone rather
>       in some other zone.


Interesting.


>

IOW the actual live data is pretty much the same, but the larger binary
> has a lot more memory that's "allocated from the OS but kept in some
> free list".  How do the
>
>    Pure-hashed: <FOO>
>    Dumping under the name emacs
>    <BAR> pure bytes used
>
> compare between the two builds?


I'll check and report back.

[-- Attachment #2: Type: text/html, Size: 1476 bytes --]

Re: Windows: Emacs 24.1 binary size vs 24.2 binary size

[Óscar Fuentes]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> I'd like to have an answer just in case anybody else notices after I
> upload the release build. Any ideas?

Give bisection a try. There are a small number of revisions between
those two releases. If the culprit is a specific change, you'll find it
with 7 builds or so.