From: Roland Orre <orre@nada.kth.se>
Cc: guile-user@gnu.org, guile-devel@gnu.org
Subject: Re: About shared substrings (now working)
Date: Wed, 21 Jan 2004 06:21:14 +0100 [thread overview]
Message-ID: <1074662474.6727.396.camel@localhost> (raw)
In-Reply-To: <87smiajeut.fsf@zagadka.ping.de>
On Wed, 2004-01-21 at 01:59, Marius Vollmer wrote:
> Roland Orre <orre@nada.kth.se> writes:
>
> > The reason I have used shared substrings is because of the side
> > effects. I was very happy when the make-shared-substring function
> > was introduced in 93 or 94. This made it possible for me to make
> > tremendous speedups when reading fix length text records and be able
> > to immediately treat the different fields of each record with scheme
> > standard conversion routines.
>
> Hmm, maybe should be using a more low-level data type than string for
> this kind of raw processing. Did you consider using uniform byte
> vectors, either from (srfi srfi-4) or from make-uniform-vector? Just
> a thought...
Yes I did, but make-shared-arrays on strings doesn't give strings back,
so I wouldn't be able to use standard scheme conversion routines anyway.
I guess what you refer to is e.g. (make-uniform-vector 10 #\a) which
gives a string back. On this I can use make-shared-array which gives
a byte vector back. Is there any other type of byte vector I may have
missed?
(of course the approach above only works on text files, for general
fix width format data base files with mixed binary/ascii formats I'm
using special routines in C, but most of the files I'm dealing with
are text files so I'm often using the shared-substring approach.)
/Roland
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
prev parent reply other threads:[~2004-01-21 5:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-18 23:12 About shared substrings (now working) Roland Orre
2004-01-21 0:59 ` Marius Vollmer
2004-01-21 5:21 ` Roland Orre [this message]
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=1074662474.6727.396.camel@localhost \
--to=orre@nada.kth.se \
--cc=guile-devel@gnu.org \
--cc=guile-user@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.
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).