Skip to content
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

unify error messages, save memory #19

Closed
rurban opened this issue Sep 11, 2017 · 1 comment
Closed

unify error messages, save memory #19

rurban opened this issue Sep 11, 2017 · 1 comment

Comments

@rurban
Copy link
Owner

rurban commented Sep 11, 2017

Currently the error messages are customized to include the function name as prefix, and the argument name.
This is great for the user, but most likely memory overkill.
Normal libc's have a unique error message per number, stored globally only once. Not 100x times.

Measure the memory impact.
possibly convert to unified strings
or to fprintf("%s: %s message", __FUNCTION__, "dest"), so we can share at least the base message.

@rurban rurban added this to the 3.0 milestone Sep 11, 2017
@rurban rurban changed the title unify error messages unify error messages, save memory Sep 11, 2017
@rurban rurban removed this from the 3.0 milestone Sep 28, 2017
rurban added a commit that referenced this issue Sep 29, 2017
rurban added a commit that referenced this issue Sep 29, 2017
rurban added a commit that referenced this issue Sep 29, 2017
rurban added a commit that referenced this issue Sep 29, 2017
@rurban
Copy link
Owner Author

rurban commented Sep 30, 2017

Measured the impact: with the new errorhandling code and global errmsg table we need 30kb more,
and measuring the win with massif on the 4 so far changed unit tests measured so memory win at all.
given that the error messages degraded, it is rejected. I'll keep the branch errmsg-gh19 though

changed funcs for testing: vsnprintf_s, vsprintf_s, swprintf_s, vswprintf_s

massif test script: (darwin)

make all
test -f src/.libs/libsafec-3.0.3.dylib && strip -S src/.libs/libsafec-3.0.3.dylib
make -C tests t_vsprintf_s
strip -S tests/t_vsprintf_s
valgrind --tool=massif --massif-out-file=massif tests/t_vsprintf_s
grep -h mem_heap_B= massif | cut -c12-|sort -rn|head -n1

# 190515 errmsg
# 190515 sprintf

@rurban rurban closed this as completed Sep 30, 2017
rurban added a commit that referenced this issue Sep 30, 2017
Using less memory is more important here.
See GH #19
rurban added a commit that referenced this issue Sep 30, 2017
Using less memory is more important here, but the impact
is negative.
while there is ~30kb more memory for the new safe_strerr
there's no win in using it. the compiler is already good enough in merging
the constant strings.

See GH #19, rejected.
rurban added a commit that referenced this issue Sep 30, 2017
Using less memory is more important here, but the impact
is negative.
while there is ~30kb more memory for the new safe_strerr
there's no win in using it. the compiler is already good enough in merging
the constant strings.

See GH #19, rejected.
rurban added a commit that referenced this issue Oct 1, 2017
Using less memory is more important here, but the impact
is negative.
while there is ~30kb more memory for the new safe_strerr
there's no win in using it. the compiler is already good enough in merging
the constant strings.

See GH #19, rejected.
rurban added a commit that referenced this issue Oct 3, 2017
Using less memory is more important here, but the impact
is negative.
while there is ~30kb more memory for the new safe_strerr
there's no win in using it. the compiler is already good enough in merging
the constant strings.

See GH #19, rejected.
rurban added a commit that referenced this issue Oct 3, 2017
Using less memory is more important here, but the impact
is negative.
while there is ~30kb more memory for the new safe_strerr
there's no win in using it. the compiler is already good enough in merging
the constant strings.

See GH #19, rejected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant