经典算法不一定就是性能最好的算法

最近在学习go语言，碰到了一个例子，就动手做一做了。

题目：实现一个 fibonacci 函数，它返回一个函数（闭包），该闭包返回一个斐波纳契数列 `(0, 1, 1, 2, 3, 5, ...)`。

也许对于熟悉算法的小伙伴来说，这个题很简单，但是我这个没怎么学过的人还是花了大半个小时才琢磨出一个算法的实现：

package main

import "fmt"

func fibonacci() func() int {
	var x, y , z = 0, 0, 0
	return func() int {
		var sun int
		if z < 2 {
			sun = x + y + z
			x = y
			y = sun
		} else {
			sun = x + y
			x = y
			y = sun
		}
		z++
		return sun
	}
}

func main() {
	f := fibonacci()
	for i := 0; i < 10; i++ {
		fmt.Println(f())
	}
}

我知道网上有现成的算法，所以上网搜一下到底是怎么实现的，然后我就知道自己有多low了

看完就想起来以前看过类似的算法了，对比自己写的算法，感觉真的有点low。

重新对照这个定义写了一个：

package main

import "fmt"

func fibonacci() func() int {
	var index int
	return func() int {
		result := count(index)
		index ++
		return result
	}
}

func count(num int) int{
	var sun int
	switch num {
	case 0: sun = 0
	case 1: sun = 1
	default:
		sun = count(num - 1) + count(num -2)
	}
	return sun
}


func main() {
	f := fibonacci2()
	for i := 0; i < 10; i++ {
		fmt.Println(f())
	}
}

也许写得不完美，但是毕竟刚开始学习go吗，所以原谅自己了。

然后习惯性的把main函数中的i改成100，测试一下，发现竟然没有想象的那样直接一堆结果出来，越到后面，结果出来的越慢。

然后我切换到自己写的算法，测试这种情况，结果一运行就出来了。

为什么会发生这样的事呢？其实递归调用，如果次数越多消耗的性能是越大的；而我的算法由于保存了前两步的结果，所以计算速度并不会因为数据的“增大”而影响性能。

突然意识到，原来所谓的那些“标准”算法，对于计算机应用来说并不一定是性能最佳的。

记录下来这次的“意外”，以此警示自己。