This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
On March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that
A collection of tips for when you need to minimize the number of allocations in your Go programs.
Use the go profiler to identify which parts of your program are responsible for most allocations.
Most of these tricks cause a tradeoff between reducing memory allocations and other aspects (including e.g. higher peak memory usage, higher CPU usage, lower maintainability, higher probability of introducing subtle bugs). Only apply these tricks if the tradeoff in every specfic case is globally positive.
| I'm not very familiar with LSP/LSIF so far, but gave a quick read and here's a summary of LSP/LSIF vs Kythe: | |
| - Documentation: LSP/LSIF protocol seems well documented. Kythe schema is a bit more dense, protocol needs digging around in .proto files (which are OK though). | |
| - Generally, Kythe pipeline needs more implicit knowledge to use - some online posts might address these though. | |
| - Windows: Kythe serving tools run on Linux, though some Docker magic might be available. | |
| - In Kythe, the storage format and the serving protocol are more separated, while LSIF tries to maintain serialized LSP responses. | |
| - In fact, Kythe has no standard storage format (the reference implementation uses some columnar protobufs AFAIK) |
| // Taken from the Rust code base: https://github.com/rust-lang/rust/blob/3809bbf47c8557bd149b3e52ceb47434ca8378d5/src/libstd/sys_common/mod.rs#L124 | |
| // Computes (value*numer)/denom without overflow, as long as both | |
| // (numer*denom) and the overall result fit into i64 (which is the case | |
| // for our time conversions). | |
| int64_t int64MulDiv(int64_t value, int64_t numer, int64_t denom) { | |
| int64_t q = value / denom; | |
| int64_t r = value % denom; | |
| // Decompose value as (value/denom*denom + value%denom), | |
| // substitute into (value*numer)/denom and simplify. | |
| // r < denom, so (denom*numer) is the upper bound of (r*numer) |
| // Package main is a sample macOS-app-bundling program to demonstrate how to | |
| // automate the process described in this tutorial: | |
| // | |
| // https://medium.com/@mattholt/packaging-a-go-application-for-macos-f7084b00f6b5 | |
| // | |
| // Bundling the .app is the first thing it does, and creating the DMG is the | |
| // second. Making the DMG is optional, and is only done if you provide | |
| // the template DMG file, which you have to create beforehand. | |
| // | |
| // Example use: |
We Gophers, love table-driven-tests, it makes our unittesting structured, and makes it easy to add different test cases with ease.
Let’s create our table driven test, for convenience, I chose to use t.Log as the test function.
Notice that we don't have any assertion in this test, it is not needed to for the demonstration.
func TestTLog(t *testing.T) {
t.Parallel()
| # Description: Boxstarter Script | |
| # Author: Jess Frazelle <[email protected]> | |
| # Last Updated: 2017-09-11 | |
| # | |
| # Install boxstarter: | |
| # . { iwr -useb http://boxstarter.org/bootstrapper.ps1 } | iex; get-boxstarter -Force | |
| # | |
| # You might need to set: Set-ExecutionPolicy RemoteSigned | |
| # | |
| # Run this boxstarter by calling the following from an **elevated** command-prompt: |
| Thread 1 "foo" hit Breakpoint 1, fmt.Printf (format="%v\n", a= []interface {} = {...}, n=859530404224, err=...) at /usr/lib/golang/src/fmt/print.go:196 | |
| 196 func Printf(format string, a ...interface{}) (n int, err error) { | |
| (gdb) disas | |
| Dump of assembler code for function fmt.Printf: | |
| => 0x000000000045a700 <+0>: mov %fs:0xfffffffffffffff8,%rcx | |
| 0x000000000045a709 <+9>: cmp 0x10(%rcx),%rsp | |
| 0x000000000045a70d <+13>: jbe 0x45a7f2 <fmt.Printf+242> | |
| 0x000000000045a713 <+19>: sub $0x60,%rsp | |
| 0x000000000045a717 <+23>: xor %ebx,%ebx | |
| 0x000000000045a719 <+25>: xor %ebx,%ebx |
A two-pass paletted pixel-scaling algorithm that uses weighting counting of adjacent colors and a fitness function (for tie-breaking) to create a 2x scale image.
This is not an efficient implementation, just a quick-and-dirty proof of concept. So it is mainly useful for offline rendering right now, but a few optimizations to create less temporary memory and it could be made pretty quick. In particular, the best_sample function will create a dictionary every call, resulting in a lot of garbage. This algorithm could directly work on an indexed image instead and then the weight array be a fixed-length array that is the size of the image color palette (possibly 16 or 256-color or whatever) that's shared between calls and just cleared before use, and then this should result in way fewer allocations. Also somebody could write it in a systems language like C++ or Rust instead of Python -- which would also help a lot, and hopefully wouldn't be too bad to port.
Tu
