-
Notifications
You must be signed in to change notification settings - Fork 500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add zfree_with_size #453
base: unstable
Are you sure you want to change the base?
Add zfree_with_size #453
Changes from all commits
0a2d984
2310767
37ad930
21acd10
0c2048d
72e6b28
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -195,7 +195,7 @@ sds sdsdup(const sds s) { | |
/* Free an sds string. No operation is performed if 's' is NULL. */ | ||
void sdsfree(sds s) { | ||
if (s == NULL) return; | ||
s_free((char *)s - sdsHdrSize(s[-1])); | ||
s_free_with_size(sdsAllocPtr(s), sdsAllocSize(s)); | ||
} | ||
|
||
/* Set the sds string length to the length as obtained with strlen(), so | ||
|
@@ -369,7 +369,7 @@ sds sdsResize(sds s, size_t size, int would_regrow) { | |
* We aim to avoid calling realloc() when using Jemalloc if there is no | ||
* change in the allocation size, as it incurs a cost even if the | ||
* allocation size stays the same. */ | ||
bufsize = zmalloc_size(sh); | ||
bufsize = sdsAllocSize(s); | ||
alloc_already_optimal = (je_nallocx(newlen, 0) == bufsize); | ||
#endif | ||
if (!alloc_already_optimal) { | ||
|
@@ -412,8 +412,13 @@ sds sdsResize(sds s, size_t size, int would_regrow) { | |
* 4) The implicit null term. | ||
*/ | ||
size_t sdsAllocSize(sds s) { | ||
size_t alloc = sdsalloc(s); | ||
return sdsHdrSize(s[-1]) + alloc + 1; | ||
char type = s[-1] & SDS_TYPE_MASK; | ||
/* SDS_TYPE_5 header doesn't contain the size of the allocation */ | ||
if (type == SDS_TYPE_5) { | ||
return s_malloc_size(sdsAllocPtr(s)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess this is currently my only concern with this PR. IIUC before this PR this would have been a very slim and trivial operation to call sdsAllocSize for SDS_TYPE_5, but now this will become more expensive. I guess in your tests this is being compensated by the fact that we eliminated it in free, but in some cases (like evictions) we might experience overhead? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually I see it is mainly used for AOF buf size. So I guess the concern is minor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess my main point here is that we do not optimize SDS_TYPE_5 in this pr but we do impact the way we calculate it's allocation size. This makes sense from cleaner code maybe, but I wonder if changing it is something we want. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. anyway, since it DOES make the sdsResize and sdsFree code much cleaner I am in favor of approving this PR. (maybe @madolson will think differently?) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also note that SDS_TYPE_5 will not be used for AOF. AOF buffer is initialized with an empty SDS to be expanded later. In this case we use SDS_TYPE_8. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree. I thought more about the future uses of sdsAllocSize |
||
} else { | ||
return sdsHdrSize(type) + sdsalloc(s) + 1; | ||
} | ||
} | ||
|
||
/* Return the pointer of the actual SDS allocation (normally SDS strings | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel this is ugly AND I feel this is not your fault.
The mix between requested length and allocated size is non intuitive and error prone.
I suggest:
1/ sdsalloc() will explicitly refuse to work for SDS_TYPE_5 by asserting
case SDS_TYPE_5: assert(0, "Type 5 does not have alloc")
which is fair as Type 5 does not have alloc value and any answer is wrong
2/ similarly sdsAllocSize function is simply and will fail spectacularly on Type 5
And thus, should never be called for TYPE_5
3/ If its interesting anywhere to anyone... add a function which explicitly fuse the meaning and with a very descriptive comment as to what it actually returns
I suspect this function is not really needed at all
4/ And just here in
sdsFree
do the if else...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just peeked and following my suggestion will actually unnecessarily bloat this PR.
So I am OK with the PR as is... and its worth considering a future cleanup in a separate PR