From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 567DC2E57D for ; Mon, 20 May 2019 05:06:38 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETXvTYd-02sW for ; Mon, 20 May 2019 05:06:38 -0400 (EDT) Received: from smtp10.mail.ru (smtp10.mail.ru [94.100.181.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 9C0F02E193 for ; Mon, 20 May 2019 05:06:37 -0400 (EDT) Date: Mon, 20 May 2019 12:06:34 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH v2 1/2] buffer: port static allocator to Lua Message-ID: <20190520090634.GA3061@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org * Vladislav Shpilevoy [19/05/19 01:15]: > 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. > > This commit exposes the allocator to Lua, which suffers from > lack of ability to pass values by pointers into FFI functions, > nor has a stack to allocate small buffers like 'char[256]'. > Also these allocations complicate and slow down GC job. > > Static allocator solves most of these problems provindg a way to > swiftly allocate temporary memory blocks. > > A simple micro benchmark showed, that ffi.new() vs > buffer.static_alloc() is ~100 times slower, even on small > allocations of 1Kb, and ~1.5 times slower on tiny allocations > of 10 bytes. The results do not account GC. It is remarkable, > buffer.static_alloc() speed does not depend on size, while > ffi.new() strongly depends. LGTM. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32