Olivier Galibert wrote:
On Wed, Apr 19, 2000 at 01:32:18AM -0700, Ben Wing wrote:
> you can't do alloca in an inline fun.
Fuck.
> > - alloca() doesn't go well with string concatenation (no realloca)
>
> only if you always allocate exactly what you need. cf my Dynarr code.
I'll have a look.
> > - alloca() bites you if you try to return one of these strings to a
> > caller or change a string which was given to you through a function
> > call
>
> did you miss this?
>
> ----- Moving to the heap -----
>
> eito_malloc (eistr):
> eifree (eistr):
> eito_alloca (eistr):
No, I didn't miss it. That is going to make the code as intuitive as
gcpro(). And as stable. Bad karma.
i doubt it. we'll see when i start using this.
> > - we'll need a kind of sprintf
>
> probably true ... but you could always pull out the raw data and use doprnt().
Yikes. What about mule?
completely mule-safe. i know -- i rewrote it from scratch to be this way.
> > - dynamically allocated strings tend to add a whole lot of overhead in
> > all mutating operations to check whether they need to be extended.
>
> this doesn't make sense to me. one if statement?
Once upon a time, I started writing a web interface to Jim Breen's
edict (japanese-english dictionary). In the first tests, I was
generating the page by concatenating characters to a dynamic string
(which was doing exponential reallocation, starting at 4K and doubling
the size each time).
On the biggest result (100 entries), building the page was taking 20s.
I changed the code to do the test once per entry, allocating at least
4K in advance (which was enough for any entry) and using pointers to
directly write the data.
New time: 0.05s.
i don't believe this. there must have been some other problem, i.e. your original
code was sufficiently badly rewritten to be O(N^2).
> true ... but better to be correct than fast. most of the time, this will not
> be used for huge chunks of data, and it really won't matter. if you really
care
> about efficiency, there are other (but less convenient) ways, e.g. use
> TO_EXTERNAL_FORMAT directly.
Efficiency should not be harder.
true, but there's a tradeoff between extra work using lower-level funs and extra
impl.
work on eistrings.
OG.
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also
http://www.666.com/ben/typing.html.