Re: Recursive subroutine for reading null-terminated string
- From: nospam@xxxxxxxxxxxxx (Richard Maine)
- Date: Tue, 25 Nov 2008 13:20:43 -0800
<vc4@xxxxxxxxxx> wrote:
Another approach is to gradually increase the size by realocating on the
fly as you read.
I was (wrongly) thinking that this approach is essentially the same
thing as my recursive procedure, but my solution is more elegant/
compact. Of course I did not take into account the overhead.
I'd have called your approach simillar to the linked list one, with the
list being in the call stack.
And I suppose one person's "elegant" is another person's "obscure;" that
has been noted before in other contexts. Give the recursive version to a
random collection of reasonably Fortran-proficient users. Give my
growing allocation version to another random collection from the same
set of people. Want to place any bets as to which group will on the
average take less time to figure out what is going on? Not to speak of
the percentages that won't manage to figure it out at all? I'd place
good money on the outcome; too bad it isn't practical to actually run
the experiment with a suitable group of statistically significant size.
Another approach to the whole thing is to build a linked list
I have assumed that linked list is a very inefficient way of storing
large arrays. I thought that normal arrays are allocated a single
memory chunk, whereas a linked list is a collection of single
character units with pointers linking each element to the next one.
Hence there is no direct access to elements in the middle, and
everything becomes slow. Am I wrong here? I suppose if the linked list
contains large chunks of data rather than single characters, this will
not be a problem.
I'd say you were correct. That's why I suggested that a linked list
approach would typically have a linked list of blocks, each of which
contains multiple elements. You can make the blocks some "reasonable"
size to balance between the per-block overhead versus the waste of
unused space in the last block.
Is memory allocation in general a serious problem in terms of speed/
overhead? For instance, is repeated reading of chunks of data into a
pre-allocated array significantly better than allocating the exact
size to the array every time the data are read, and deallocating
afterwards?
Yes... and no. Memory allocation can be a significant issue. As Glen
says, I definitely try to avoid doing it in time-critical inner loops.
On the other hand, I/O is also a significant speed issue, disk being
several orders of magnitude slower than ram; that's why caching is
beneficial. So if you are doing I/O of an array, odds are that the time
to allocate the array to the exact size isn't going to dominate the I/O
time.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
.
- Follow-Ups:
- Re: Recursive subroutine for reading null-terminated string
- From: Glen Herrmannsfeldt
- Re: Recursive subroutine for reading null-terminated string
- References:
- Prev by Date: Re: Compilation Error
- Next by Date: Re: Recursive subroutine for reading null-terminated string
- Previous by thread: Re: Recursive subroutine for reading null-terminated string
- Next by thread: Re: Recursive subroutine for reading null-terminated string
- Index(es):
Relevant Pages
|
