From xemacs-m  Fri Jan 10 05:31:09 1997
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with ESMTP
	  id FAA23373 for <xemacs-beta@xemacs.org>; Fri, 10 Jan 1997 05:31:09 -0600 (CST)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.4/8.8.3) with ESMTP id DAA08519 for <xemacs-beta@xemacs.org>; Fri, 10 Jan 1997 03:30:02 -0800 (PST)
Received: from 666.com (shellx.best.com [206.86.0.11]) by shellx.best.com (8.8.4/8.8.3) with SMTP id DAA15578 for <xemacs-beta@xemacs.org>; Fri, 10 Jan 1997 03:28:20 -0800 (PST)
From: Ben Wing <ben@666.com>
Date: Fri, 10 Jan 1997 03:28:20 -0800 (PST)
To: David Moore <dmoore@UCSD.EDU>
cc: xemacs-beta@xemacs.org
Subject: Re: Inserting into a buffer.
In-Reply-To: <rvvi96m11p.fsf@sdnp5.ucsd.edu>
Message-ID: <Pine.SGI.3.95.970110032511.9904A-100000@shellx.best.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Keep up the good work!  I'm glad someone is looking at this and
understanding it.  When I did the extent rewrite I had two goals:
correctness and speed in the limiting case (lots of extents).  I
didn't spend too much time optimizing the few-extent case ...

On 9 Jan 1997, David Moore wrote:

> Steven L Baur <steve@miranova.com> writes:
> 
> > David> The culprits seem multiple, and at least one is very strange
> > David> (munmap).
> >
> > That must be coming from the relocating allocator.  Try running the
> > same test with it disabled from configure.
> 
> 	Results on Hrvoje's benchmark are improved under solaris if the
> relocating allocator is turned off.  (180sec->150sec with -O4 on 19.15b7
> for sparcserver5 with 64M).  I may look into the code, because I don't
> see why mmap should be costing that much more.
> 
> > David> Flat profile:
> > 
> > David> Each sample counts as 0.01 seconds.
> > David>   %   cumulative   self              self     total           
> > David>  time   seconds   seconds    calls  ms/call  ms/call  name    
> > David>   9.85    115.71    31.56  6005492     0.01     0.01  map_extents_bytind
> > David>   8.55    143.11    27.40  2000391     0.01     0.04  buffer_insert_string_1
> 
> 
> > I thought extents were supposed to be fast?
> 
> 	The patch below speeds up inserts and other operaations on
> buffers with no extents in them.  On Hrvoje's benchmark: 180sec->120sec.
> Combined with disabling the mmap memory cut the time in half.  The patch
> quick exits routines which will do a bunch of costly function calls
> before failing all of their various checks and returning default values.
> 
> 	map_extents_bytind is slower than it should be, but I'm
> concerned about really playing with it.  Certainly I think the readonly
> checks done for string inserting might be well served if
> map_extents_bytind had a special case for 0 length extents, such as
> those generated by verify_extent_modification when called by
> barf_if_buffer_read_only working on the behalf of
> buffer_insert_string_1.  Since the extent is 0 length, and
> verify_extent_modification doesn't do any insertions or modifications as
> it proceeds.  And you should only need to scan the SOE and not go on to
> also do the range scan (which it seems to, although I need to stare at
> the code another 20 times or more. :)
> 
> 
> diff --unified extents.c.orig extents.c
> --- extents.c.orig	Thu Jan  9 23:37:29 1997
> +++ extents.c	Thu Jan  9 23:37:34 1997
> @@ -1968,8 +1968,10 @@
>        assert (!extent_detached_p (after));
>      }
>  
> -  if (!buffer_or_string_extent_list (obj))
> +  el = buffer_or_string_extent_list (obj);
> +  if (!el || !extent_list_num_els(el))
>      return;
> +  el = 0;
>  
>    st = buffer_or_string_bytind_to_memind (obj, from);
>    en = buffer_or_string_bytind_to_memind (obj, to);
> @@ -2315,8 +2317,9 @@
>  #endif
>    el = buffer_or_string_extent_list (obj);
>  
> -  if (!el)
> +  if (!el || !extent_list_num_els(el))
>      return;
> +
>    /* IMPORTANT! Compute the starting positions of the extents to
>       modify BEFORE doing any modification!  Otherwise the starting
>       position for the second time through the loop might get
> @@ -2516,7 +2519,7 @@
>      buffer_or_string_absolute_end_byte (obj) :
>        buffer_or_string_accessible_end_byte (obj);
>  
> -  if (!bel)
> +  if (!bel || !extent_list_num_els(bel))
>      return limit;
>  
>    sel = buffer_or_string_stack_of_extents_force (obj)->extents;
> @@ -2556,7 +2559,7 @@
>      buffer_or_string_absolute_begin_byte (obj) :
>        buffer_or_string_accessible_begin_byte (obj);
>  
> -  if (!bel)
> +  if (!bel || !extent_list_num_els(bel))
>      return limit;
>  
>    sel = buffer_or_string_stack_of_extents_force (obj)->extents;
> 
> 
> -- 
> David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
> UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
> La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
> <URL:http://oj.egbt.org/dmoore/>    |
> 

