sum

func ConcurrentSum1 ¶

func ConcurrentSum1(fileName string) (ret int64, _ error)

ConcurrentSum1 performs sum concurrently. A lot slower than ConcurrentSum3. An example of pessimisation. Read more in "Efficient Go"; Example 10-10.

func ConcurrentSum2 ¶

func ConcurrentSum2(fileName string, workers int) (ret int64, _ error)

ConcurrentSum2 performs sum concurrently. A lot slower than ConcurrentSum3. An example of pessimisation. Read more in "Efficient Go"; Example 10-11.

func ConcurrentSum3 ¶

func ConcurrentSum3(fileName string, workers int) (ret int64, _ error)

ConcurrentSum3 uses coordination free sharding to perform more efficient computation. Read more in "Efficient Go"; Example 10-12.

func ConcurrentSum4 ¶

func ConcurrentSum4(fileName string, workers int) (ret int64, _ error)

ConcurrentSum4 is like ConcurrentSum3, but it reads file in sharded way too. Read more in "Efficient Go"; Example 10-13.

func ParseInt ¶

func ParseInt(input []byte) (n int64, _ error)

ParseInt is 3-4x times faster than strconv.ParseInt or Atoi.

func ScanLines ¶

func ScanLines(data []byte, atEOF bool) (advance int, token []byte, err error)

func Sum ¶

func Sum(fileName string) (ret int64, _ error)

Sum is a naive implementation and algorithm for summing integers from file. Read more in "Efficient Go"; Example 4-1.

func Sum2 ¶

func Sum2(fileName string) (ret int64, _ error)

Sum2 is sum with optimized the first latency + CPU bottleneck bytes.Split. bytes.Split look complex to hande different cases. It allocates a lot causing It looks like the algo is simple enough to just implement on our own (tried scanner := bufio.NewScanner(f) but it's slower). 30% less latency and 5x less memory than Sum. Read more in "Efficient Go"; Example 10-3.

func Sum2_scanner ¶

func Sum2_scanner(fileName string) (ret int64, err error)

Sum2_scanner is a sum attempting using scanner. Actually slower than Sum2, but uses less memory.

func Sum3 ¶

func Sum3(fileName string) (ret int64, _ error)

Sum3 is a sum with optimized the second latency + CPU bottleneck: string conversion. On CPU profile we see byte to string conversion not only allocate memory, but also takes precious time. Let's perform zeroCopy conversion. 2x less latency memory than Sum2. Read more in "Efficient Go"; Example 10-4.

func Sum4 ¶

func Sum4(fileName string) (ret int64, err error)

Sum4 is a sum with optimized the second latency + CPU bottleneck: ParseInt and string conversion. On CPU profile we see that ParseInt does a lot of checks that we might not need. We write our own parsing straight from byte to avoid conversion CPU time. 2x less latency, same mem as Sum3. Read more in "Efficient Go"; Example 10-5.

func Sum4_atoi ¶

func Sum4_atoi(fileName string) (ret int64, err error)

func Sum5 ¶

func Sum5(fileName string) (ret int64, err error)

Sum5 is like Sum4, but noticing that it takes time to even allocate 21 MB on heap (and read file to it). Let's try to use scanner instead. Slower than Sum4 and Sum6 because scanner is not optimized for this...? Scanner takes 73% of CPU time. Read more in "Efficient Go"; Example 10-7.

func Sum5_line ¶

func Sum5_line(fileName string) (ret int64, err error)

func Sum6 ¶

func Sum6(fileName string) (ret int64, err error)

Sum6 is like Sum4, but trying to use max 10 KB of mem without scanner and bulk read. Assuming no integer is larger than 8 000 digits. Read more in "Efficient Go"; Example 10-8.

func Sum6Reader ¶

func Sum6Reader(r io.Reader, buf []byte) (ret int64, err error)

func Sum7 ¶

func Sum7(fileName string) (int64, error)

Sum7 is cached (cheating!) (: Read more in "Efficient Go"; Example 10-15.