unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Roland Orre <orre@nada.kth.se>
Subject: About shared substrings
Date: Fri, 16 Jan 2004 21:35:06 +0100	[thread overview]
Message-ID: <1074285306.6739.178.camel@localhost> (raw)
In-Reply-To: <rmillo7u2pv.fsf@fnord.ir.bbn.com>

Today I became really impressed.
For me shared substrings was an essential feature of guile as this made
me able to speed up pure scheme based reading of fixed width text files
in a dramatic way as I only needed to declare a buffer and from this
buffer allocate a set of substrings corresponding to the fields of that
table. Using this scheme I didn't need to do any more memory allocations
of substrings as every field was immediately accessible by standard
scheme string conversion routines when the buffer was read.

Now when I found that shared substrings were removed from guile 1.7
I first came up with a complicated scheme using guile_gc_protect_object
but where I would have to do explicit deallocation of shared strings.

I discussed this issue with Mikael Djurfeldt today and then he came up
with the following solution:

SCM substring_table;

SCM scm_make_shared_substring (SCM parent, SCM start, SCM end)
{
  SCM substring;
  char *mem;
  int c_start, c_end;
  SCM_VALIDATE_SUBSTRING_SPEC_COPY (1, parent, mem,
                                    2, start, c_start,
                                    3, end, c_end);
  substring = scm_cell (SCM_MAKE_STRING_TAG (c_end - c_start),
                        (scm_t_bits) (mem + c_start));
  scm_hash_set_x (substring_table, substring, parent);
  return substring;
}

where the following is put in the main:
substring_table
= scm_permanent_object (scm_make_weak_key_hash_table (SCM_UNDEFINED));

This is almost magical :) It works perfectly well and I don't need to
bother about any explicit deallocation. This is also the first time I
really understand the purpose of these weak hash tables. For weak hash
tables the hash entry will be garbage collected first when the key is
seen as garbage. With this scheme we still have the same essential
functionality from my perspective about shared substrings but we do
no longer need an explicit tag for shared substrings.

Mikael Djurfeldt is relly the most clever programmer I know.

	Many thanks!
	Roland Orre




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


       reply	other threads:[~2004-01-16 20:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1074242951.6739.5.camel@localhost>
     [not found] ` <rmillo7u2pv.fsf@fnord.ir.bbn.com>
2004-01-16 20:35   ` Roland Orre [this message]
2004-01-16 21:12     ` About shared substrings Neil Jerram
2004-01-17 22:34       ` Keith Wright
2004-01-16 21:54     ` Mikael Djurfeldt
2004-01-16 22:00     ` Tom Lord

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=1074285306.6739.178.camel@localhost \
    --to=orre@nada.kth.se \
    /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).