| Date | Commit message (Collapse) |
|---|
|
<time.h> is still required for gmtime_r(3), and not all versions
of <ruby.h> include <time.h>, already.
Fixes: a6463151bd1db5b9 (httpdate: favor gettimeofday(2) over time(2) for correctness, 2023-06-01)
|
|
While scanning the git@vger.kernel.org mailing list, I've
learned time(2) may return the wrong value in the first 1 to 2.5
ms of every second. While I'm not sure if the Date: response
header matters to anyone, returning the correct time seems
prudent.
Link: https://lore.kernel.org/git/20230320230507.3932018-1-gitster@pobox.com/
Link: https://inbox.sourceware.org/libc-alpha/20230306160321.2942372-1-adhemerval.zanella@linaro.org/T/
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=30200
|
|
SIZEOF_*, *2NUM and NUM2* should all be defined by ruby.h and
dependencies it pulls in since Ruby 2.0 and possibly earlier.
INT_MAX and LLONG_MAX are in limits.h which is POSIX.
HAVE_GMTIME_R is already defined by ruby/config.h, so we
shouldn't have to check for it, either.
Combined, these changes speed up extconf.rb by several seconds.
|
|
Since Ruby 2.6, it's a documented part of the API and we may depend
on it: https://bugs.ruby-lang.org/issues/9894
It's been around since the early Ruby 1.9 days, and reduces
overhead compared to relying on rb_global_variable:
https://bogomips.org/unicorn-public/20170301002854.29198-1-e@80x24.org/
|
|
rb_global_variable registers the address of the variable which
refers to the object, instead of the object itself. This adds
extra overhead to each global variable for our case, where the
variable is frozen and never changed.
Given there are currently 59 elements in this array, this saves
58 singly-linked list entries and associated malloc calls and
associated overhead in the current mainline Ruby 2.x
implementation. On 64-bit GNU libc malloc, this is already
16 * 58 = 928 bytes; more than the extra object slot and array
slack space used by the new mark array.
Mainline Ruby 1.9+ currently has a rb_gc_register_mark_object
public function which would suite our needs, too, but it is
currently undocumented, and may not be available in the future.
|
|
This allows requiring just the C extension part of "unicorn_http",
without requiring the rest of unicorn, allowing other HTTP servers
using the same parser to be slimmer.
On my x86-64 Debian 7.0 system:
text data bss dec hex filename
44026 1976 488 46490 b59a lib/unicorn_http.so
43930 1976 456 46362 b51a lib/unicorn_http.so
|
|
Extra pointers waste space in the DSO. Normally I wouldn't
care, but the string lengths are identical and this code
already made it into another project in this form.
size(1) output:
text data bss dec hex filename
before: 42881 2040 336 45257 b0c9 unicorn_http.so
after: 42499 1888 336 44723 aeb3 unicorn_http.so
ref: http://www.akkadia.org/drepper/dsohowto.pdf
|
|
This can return a static string and be significantly
faster as it reduces object allocations and Ruby method
calls for the fastest websites that serve thousands of
requests a second.
It assumes the Ruby runtime is single-threaded, but that
is the case of Ruby 1.8 and 1.9 and also what Unicorn
is all about. This change is safe for Rainbows! under 1.8
and 1.9.
|