On Thu, Aug 14, 2008 at 01:51:07AM +0200, Jehan wrote: > in mrxvt, there are several buffers. One of them is v_buffer which is > the buffer of what is written to the child program (most often bash) as > input. This one is dynamic (its size increases depending on the needs > and space is freed when only a very small part of it is used). > > We have other another buffer which is -- at the opposite -- the output > from the child program: cmdbuf_base. This one is of fixed size, > allocated from the beginning: BUFSIZ (defined as 4096 bytes in rxvt.h). > > Why not make it dynamic as well? The advantages are: > - we don't have constantly 4096 bytes for each tab, whether this is > really necessary or not. But is it such an issue 4096 bytes on current > machines with so much memory? Probably is it if we want mrxvt to work as > well on old machines? > - could there really be cases where there is so much output at once that > this implies a loss of data? I am not sure of this because in some > places there are some kind of watchdog. But at the opposite, this case > has been taken into account in at least one function: rxvt_cmd_write in > command.c. > - probably better code to be dynamic as a general matter of fact, isn't it?
Hi Jehan,
Maybe. What needs to be kept in mind are the following:
1. The size is only about 4k. If the amount of code required to deal
with a dynamic buffer here is comparable then it is probably not
worth it.
2. As far as I remember, the input buffer grows when needed, but
does not shrink when too big. This should of course be avoided.
Given the small size of these arrays, and the short amount of developer
resources we have perhaps it would be better to leave these as static.
I'd go so far as to suggesting we convert the v_buffer's to (small)
static arrays...
> The best advantages of a static array instead of a dynamic pointer is
> not having to reallocate and check size all the time, I guess.
Yep!! It's not a good idea to call "realloc" every time the user types,
or the shell produces some input.
> Of course there shall be some minimum buffer size (considering in any
> terminal, we will see some output) and we could decide to free only
> when there is something like 80% of the space which is wasted. This
> way we won't reallocate too much, but still be dynamic in the use...
That should be OK.
> What do you think?
If you're willing to implement it, it should improve Mrxvt's memory
usage. It would also be good to add some code reducing the size of
v_buffer when it's too big,
GI
> P.S.: I saw a similar comment by Gautam about the tabs in rxvlib.h:
>
> /*
> * term_t structures and pointers.
> *
> * 2006-08-18 gi1242 TODO: This should be an array that grows
> dynamically in
> * size. Plus we should only reserve enough memory for a our currently
> * displayed term structures.
> */
>
> They are indeed initialized the same way as the buffer, by a fixed
> length array of size MAX_PAGES. Probably can this be changed as well
> later on. So instead of loading from the start MAX_PAGES with each one
> a buffer of BUFSIZ, the next version of mrxvt may be able to use only
> the necessary memory at all time...
Re-allocing here would be totally OK. A new tab is created very
infrequently (as opposed to typing / reading data). So a rather 'stupid'
realloc every time a new tab is created / closed should be OK.
GI
--
Hidden DOS secret: add BUGS=OFF to your CONFIG.SYS
pgpY8eZBfsKuJ.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Materm-devel mailing list Materm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/materm-devel mrxvt home page: http://materm.sourceforge.net
