A look at allegro/bigcache: 8.2k stars on GitHub, written primarily in Go. Efficient cache for gigabytes of data written in Go.
Snapshot summary built from the project's own GitHub metadata — there's no written TopGit review yet. The page will update automatically when a full review is published.
WHY NO REVIEW YET
TopGit writes full reviews for the most-starred, most-requested repositories. This page is a snapshot until then — see the READ ME tab for the original README in full.
Fast, concurrent, evicting in-memory cache written to keep big number of entries without impact on performance.
BigCache keeps entries on heap but omits GC for them. To achieve that, operations on byte slices take place,
therefore entries (de)serialization in front of the cache will be needed in most use cases.
When cache load can be predicted in advance then it is better to use custom initialization because additional memory
allocation can be avoided in that way.
import (
"context"
"fmt"
"log"
"time"
"github.com/allegro/bigcache/v3"
)
config := bigcache.Config {
// number of shards (must be a power of 2)
Shards: 1024,
// time after which entry can be evicted
LifeWindow: 10 * time.Minute,
// Interval between removing expired entries (clean up).
// If set to <= 0 then no action is performed.
// Setting to < 1 second is counterproductive — bigcache has a one second resolution.
CleanWindow: 5 * time.Minute,
// rps * lifeWindow, used only in initial memory allocation
MaxEntriesInWindow: 1000 * 10 * 60,
// max entry size in bytes, used only in initial memory allocation
MaxEntrySize: 500,
// prints information about additional memory allocation
Verbose: true,
// cache will not allocate more memory than this limit, value in MB
// if value is reached then the oldest entries can be overridden for the new ones
// 0 value means no size limit
HardMaxCacheSize: 8192,
// callback fired when the oldest entry is removed because of its expiration time or no space left
// for the new entry, or because delete was called. A bitmask representing the reason will be returned.
// Default value is nil which means no callback and it prevents from unwrapping the oldest entry.
OnRemove: nil,
// OnRemoveWithReason is a callback fired when the oldest entry is removed because of its expiration time or no space left
// for the new entry, or because delete was called. A constant representing the reason will be passed through.
// Default value is nil which means no callback and it prevents from unwrapping the oldest entry.
// Ignored if OnRemove is specified.
OnRemoveWithReason: nil,
}
cache, initErr := bigcache.New(context.Background(), config)
if initErr != nil {
log.Fatal(initErr)
}
cache.Set("my-unique-key", []byte("value"))
if entry, err := cache.Get("my-unique-key"); err == nil {
fmt.Println(string(entry))
}
LifeWindow & CleanWindow
LifeWindow is a time. After that time, an entry can be called dead but not deleted.
CleanWindow is a time. After that time, all the dead entries will be deleted, but not the entries that still have life.
Benchmarks
Three caches were compared: bigcache, freecache and map.
Benchmark tests were made using an
i7-6700K CPU @ 4.00GHz with 32GB of RAM on Ubuntu 18.04 LTS (5.2.12-050212-generic).
Writes and reads in bigcache are faster than in freecache.
Writes to map are the slowest.
GC pause time
go version
go version go1.13 linux/amd64
go run caches_gc_overhead_comparison.go
Number of entries: 20000000
GC pause for bigcache: 1.506077ms
GC pause for freecache: 5.594416ms
GC pause for map: 9.347015ms
go version
go version go1.13 linux/arm64
go run caches_gc_overhead_comparison.go
Number of entries: 20000000
GC pause for bigcache: 22.382827ms
GC pause for freecache: 41.264651ms
GC pause for map: 72.236853ms
Test shows how long are the GC pauses for caches filled with 20mln of entries.
Bigcache and freecache have very similar GC pause time.
Memory usage
You may encounter system memory reporting what appears to be an exponential increase, however this is expected behaviour. Go runtime allocates memory in chunks or 'spans' and will inform the OS when they are no longer required by changing their state to 'idle'. The 'spans' will remain part of the process resource usage until the OS needs to repurpose the address. Further reading available here.
How it works
BigCache relies on optimization presented in 1.5 version of Go (issue-9477).
This optimization states that if map without pointers in keys and values is used then GC will omit its content.
Therefore BigCache uses map[uint64]uint32 where keys are hashed and values are offsets of entries.
Entries are kept in byte slices, to omit GC again.
Byte slices size can grow to gigabytes without impact on performance
because GC will only see single pointer to it.
Collisions
BigCache does not handle collisions. When new item is inserted and it's hash collides with previously stored item, new item overwrites previously stored value.
Bigcache vs Freecache
Both caches provide the same core features but they reduce GC overhead in different ways.
Bigcache relies on map[uint64]uint32, freecache implements its own mapping built on
slices to reduce number of pointers.
Results from benchmark tests are presented above.
One of the advantage of bigcache over freecache is that you don’t need to know
the size of the cache in advance, because when bigcache is full,
it can allocate additional memory for new entries instead of
overwriting existing ones as freecache does currently.
However hard max size in bigcache also can be set, check HardMaxCacheSize.
HTTP Server
This package also includes an easily deployable HTTP implementation of BigCache, which can be found in the server package.
More
Bigcache genesis is described in allegro.tech blog post: writing a very fast cache service in Go
License
BigCache is released under the Apache 2.0 license (see LICENSE)
The most recent commit recorded on allegro/bigcache was 5 days ago, based on the GitHub push timestamp. The repository has 610 forks — one of the better signals of community interest.
How many stars does allegro/bigcache have?
allegro/bigcache has 8.2k GitHub stars — refresh the page for the live number, or check github.com/allegro/bigcache. TopGit mirrors GitHub's count but does not claim minute-by-minute accuracy.
What language is allegro/bigcache written in?
allegro/bigcache is written primarily in Go. GitHub's language field is based on the largest share of bytes in the default branch.
What topics is allegro/bigcache associated with?
GitHub's repository topics for allegro/bigcache: "cache", "caching", "golang-library", "hacktoberfest", "performance". TopGit's editorial category is open-source.
Where do I read more about allegro/bigcache?
This TopGit page is a snapshot — the READ ME tab shows the project's own README content (links stripped, images preserved). The GitHub repository at github.com/allegro/bigcache is the definitive source.
Read full README in the tab above.
Curious whether bigcache is right for you?
Let ChatGPT, Claude, or Perplexity look into it — click below and see what AI actually says about bigcache.