mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-27 13:53:31 +01:00
Yet another buffer RAM patch: tNever ever ever keep a buffer memory chunk around for an empty buffer that could go on the freelist. This wants profiling to make sure that performance doesnt suffer.
svn:r10993
This commit is contained in:
parent
34a3a5e2f4
commit
9260a824ef
@ -1,3 +1,10 @@
|
||||
Changes in version 0.2.0.4-alpha - 2007-??-??
|
||||
o Minor features (performance):
|
||||
- Be even more aggressive about releasing RAM from small
|
||||
empty buffers. Thanks to our free-list code, this shouldn't be too
|
||||
performance-intensive.
|
||||
|
||||
|
||||
Changes in version 0.2.0.3-alpha - 2007-07-29
|
||||
o Major features:
|
||||
- The first pieces of our "bridge" design for blocking-resistance
|
||||
|
@ -486,7 +486,13 @@ buf_remove_from_front(buf_t *buf, size_t n)
|
||||
if (buf->datalen) {
|
||||
buf->cur = _wrap_ptr(buf, buf->cur+n);
|
||||
} else {
|
||||
buf->cur = buf->mem;
|
||||
if (IS_FREELIST_SIZE(buf->len)) {
|
||||
buf->highwater = 0;
|
||||
if (add_buf_mem_to_freelist(buf))
|
||||
return;
|
||||
} else {
|
||||
buf->cur = buf->mem;
|
||||
}
|
||||
}
|
||||
check();
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user