unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel@gnu.org
Subject: Re: Optimizing ‘string=’
Date: Tue, 22 Jun 2010 23:32:43 +0200	[thread overview]
Message-ID: <87eifyhhxg.fsf@gnu.org> (raw)
In-Reply-To: <m37hlq94fy.fsf@pobox.com> (Andy Wingo's message of "Tue, 22 Jun 2010 22:51:13 +0200")

Hi,

Andy Wingo <wingo@pobox.com> writes:

> On Tue 22 Jun 2010 21:40, ludo@gnu.org (Ludovic Courtès) writes:
>
>> @@ -1168,6 +1168,21 @@ SCM_DEFINE (scm_string_eq, "string=", 2, 4, 0,
>>  	    "value otherwise.")
>>  #define FUNC_NAME s_scm_string_eq
>>  {
>> +  if (SCM_LIKELY (scm_i_is_narrow_string (s1) == scm_i_is_narrow_string (s2)
>> +		  && SCM_UNBNDP (start1) && SCM_UNBNDP (end1)
>> +		  && SCM_UNBNDP (start2) && SCM_UNBNDP (end2)))
>> +    {
>> +      size_t len1, len2;
>> +
>> +      len1 = scm_i_string_length (s1);
>> +      len2 = scm_i_string_length (s2);
>> +
>> +      if (SCM_LIKELY (len1 == len2))
>> +	return scm_from_bool (memcmp (scm_i_string_chars (s1),
>> +				      scm_i_string_chars (s2),
>> +				      len1) == 0);
>> +    }
>> +
>
> Nasty, but OK I guess if you need it. Why not also add a fast path for
> scm_is_eq (s1, s2), or for comparing stringbufs, or something ?

Hmm yes.  Though if there are too many fast paths the whole thing ends
up being slow.  ;-)

I don’t expect (eq? s1 s2) and (eq? (string-buf s1) (string-buf s2)) to
be common enough to warrant a more specific special case, though.

>> It’s quite inelegant, but it leads to a more balanced profile:
>>
>> samples  %        symbol name
>> 8079     23.3984  scm_string_eq
>> 5649     16.3606  vm_debug_engine
>> 5624     16.2882  scm_i_str2symbol
>                     ^ What is this doing here?

I comes from the ‘load-symbol’ instruction.

Indeed, the loop’s body goes like this:

--8<---------------cut here---------------start------------->8---
  36    (new-frame)                     
  37    (load-symbol "string=")         ;; string=
  48    (link-now)                      
  49    (variable-ref)                  
  50    (load-symbol "s")               ;; s
  55    (link-now)                      
  56    (variable-ref)                  
  57    (load-symbol "s")               ;; s
  62    (link-now)                      
  63    (variable-ref)                  
  64    (mv-call 2 :L39)                ;; MV -> 74
  69    (drop)                          
  70    (br :L40)                       ;; -> 77
  74    (truncate-values 0 0)           
  77    (br :L41)                       ;; -> 36
  81    (br :L41)                       ;; -> 36
--8<---------------cut here---------------end--------------->8---

Because it’s a top-level program, “string=” is looked up at each
iteration.

If we instead do:

--8<---------------cut here---------------start------------->8---
(define s (make-string 123 #\a))

(define (foo)
  (let loop ()
    (string= s s)
    (loop)))

(foo)
--8<---------------cut here---------------end--------------->8---

we get:

--8<---------------cut here---------------start------------->8---
   0    (assert-nargs-ee/locals 0)      
   2    (br :L38)                       ;; -> 30
   6    (new-frame)                     
   7    (toplevel-ref 1)                
   9    (toplevel-ref 2)                
  11    (toplevel-ref 2)                
  13    (mv-call 2 :L39)                ;; MV -> 23
  18    (drop)                          
  19    (br :L40)                       ;; -> 26
  23    (truncate-values 0 0)           
  26    (br :L41)                       ;; -> 6
  30    (br :L41)                       ;; -> 6
--8<---------------cut here---------------end--------------->8---

and thus presumably no ‘scm_i_str2symbol’.

> And for the matter, what are the rest about?

Lookups of ‘string=’.

> Did you just do a really short profile?

Yes.

Ludo’.



  reply	other threads:[~2010-06-22 21:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-22 19:40 Optimizing ‘string=’ Ludovic Courtès
2010-06-22 20:43 ` Ludovic Courtès
2010-06-23  2:25   ` Mike Gran
2010-06-22 20:51 ` Andy Wingo
2010-06-22 21:32   ` Ludovic Courtès [this message]
2010-06-22 21:54     ` Andy Wingo
2010-07-02 13:32       ` Ludovic Courtès

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/guile/

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

  git send-email \
    --in-reply-to=87eifyhhxg.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guile-devel@gnu.org \
    --cc=wingo@pobox.com \
    /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.
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).