buffer: port static allocator to Lua
Static allocator gives memory blocks from cyclic BSS memory block of 3 pages 4096 bytes each. It is much faster than malloc, when a temporary buffer is needed. Moreover, it does not complicate GC job. Despite being faster than malloc, it is still slower, than ffi.new() of size <= 128 known in advance (according to microbenchmarks). ffi.new(size<=128) works either much faster or with the same speed as static_alloc, because internally FFI allocator library caches small blocks and can return them without malloc(). A simple micro benchmark showed, that ffi.new() vs buffer.static_alloc() is ~100 times slower on allocations of > 128 size, on <= 128 when size is not inlined. To better understand what is meant as 'inlined': this ffi.new('char[?]', < <=128 >) works ~100 times faster than this: local size = <= 128 ffi.new('char[?]', size) ffi.new() with inlined size <= 128 works faster than light, and even static allocator can't beat it.
Showing
- extra/exports 2 additions, 0 deletionsextra/exports
- src/CMakeLists.txt 1 addition, 0 deletionssrc/CMakeLists.txt
- src/box/lua/schema.lua 2 additions, 1 deletionsrc/box/lua/schema.lua
- src/lua/buffer.c 42 additions, 0 deletionssrc/lua/buffer.c
- src/lua/buffer.lua 32 additions, 0 deletionssrc/lua/buffer.lua
- src/lua/digest.lua 4 additions, 3 deletionssrc/lua/digest.lua
- src/lua/fio.lua 6 additions, 2 deletionssrc/lua/fio.lua
- src/lua/init.c 1 addition, 1 deletionsrc/lua/init.c
- src/lua/socket.lua 2 additions, 2 deletionssrc/lua/socket.lua
- src/lua/string.lua 4 additions, 2 deletionssrc/lua/string.lua
- src/lua/uri.lua 4 additions, 3 deletionssrc/lua/uri.lua
- src/lua/uuid.lua 5 additions, 4 deletionssrc/lua/uuid.lua
- test/app/buffer.result 26 additions, 0 deletionstest/app/buffer.result
- test/app/buffer.test.lua 12 additions, 0 deletionstest/app/buffer.test.lua
Loading
Please register or sign in to comment