Ecosyste.ms: Packages

An open API service providing package, version and dependency metadata of many open source software ecosystems and registries.

Top 2.8% dependent packages on proxy.golang.org
Top 1.4% dependent repos on proxy.golang.org

proxy.golang.org : modernc.org/bufs

Package bufs implements a simple buffer cache. The intended use scheme is like: The whole idea behind 'bufs' is that when calling e.g. Foo.Bar N times, then normally, without using 'bufs', there will be 2*N (in this example) []byte buffers allocated. While using 'bufs', only 2 buffers (in this example) will ever be created. For large N it can be a substantial difference. It's not a good idea to use Buffers to cache too big buffers. The cost of having a cached buffer is that the buffer is naturally not eligible for garbage collection. Of course, that holds only while the Foo instance is reachable, in the above example. The buffer count limit is intentionally "hard" (read panicking), although configurable in New(). The rationale is to prevent recursive calls, using Alloc, to cause excessive, "static" memory consumption. Tune the limit carefully or do not use Buffers from within [mutually] recursive functions where the nesting depth is not realistically bounded to some rather small number. Buffers cannot guarantee improvements to you program performance. There may be a gain in case where they fit well. Firm grasp on what your code is actually doing, when and in what order is essential to proper use of Buffers. It's _highly_ recommended to first do profiling and memory profiling before even thinking about using 'bufs'. The real world example, and cause for this package, was a first correct, yet no optimizations done version of a program; producing few MB of useful data while allocating 20+GB of memory. Of course the garbage collector properly kicked in, yet the memory abuse caused ~80+% of run time to be spent memory management. The program _was_ expected to be slow in its still development phase, but the bottleneck was guessed to be in I/O. Actually the hard disk was waiting for the billions bytes being allocated and zeroed. Garbage collect on low memory, rinse and repeat. In the provided tests, TestFoo and TestFooBufs do the same simulated work, except the later uses Buffers while the former does not. Suggested test runs which show the differences: NOTE: Alloc/Free calls must be properly nested in the same way as in for example BeginTransaction/EndTransaction pairs. If your code can panic then the pairing should be enforced by deferred calls. NOTE: Buffers objects do not allocate any space until requested by Alloc, the mechanism works on demand only. FAQ: Why the 'bufs' package name? Package name 'bufs' was intentionally chosen instead of the perhaps more conventional 'buf'. There are already too many 'buf' named things in the code out there and that'll be a source of a lot of trouble. It's a bit similar situation as in the case of package "strings" (not "string").

Registry - Source - Documentation - JSON
purl: pkg:golang/modernc.org/bufs
License: BSD-3-Clause
Latest release: over 5 years ago
First release: over 5 years ago
Namespace: modernc.org
Dependent packages: 4
Dependent repositories: 14
Stars: 0 on GitLab.com
Forks: 0 on GitLab.com
See more repository details: repos.ecosyste.ms
Last synced: 19 days ago

    Loading...
    Readme
    Loading...