作者为Apple II编写Quicktake相机照片解码程序时，发现150型号的解码速度极慢。通过分析复杂的Huffman编码算法，并针对6502处理器1MHz的性能限制进行优化，最终将解码时间从70分钟大幅缩短至1分钟。优化过程包括重构算法以适应内存限制，并克服6502处理16位运算的瓶颈。

标题：6502图像解码器优化：从70分钟到1分钟的蜕变

本文记录了作者为Apple II开发Quicktake相机图像解码器的优化历程。最初的目标是解码Quicktake 100的照片，但后来扩展到了Quicktake 150和200型号，这使得项目复杂度远超预期。

关键挑战： 1. Quicktake 150采用未公开的专有格式，基于霍夫曼编码和16位运算 2. 初始C语言实现需要70分钟解码一张图片 3. 6502处理器（1MHz）性能限制严重

优化策略： 1. 算法重构： - 放弃色彩处理（最终输出单色图像） - 减少中间缓冲区使用 - 优化像素输出索引方式

2. 数学运算优化：

• 用预计算除法表替代实时运算
• 特殊处理高频出现的除数（如48）
• 优化乘法运算（如用位移替代）

3. 霍夫曼解码改进：

• 改表查找为逐位处理
• 添加专用"丢弃"函数处理无用数据

4. 汇编级优化：

• 使用自修改代码优化内存访问
• 建立专用位移查找表
• 针对常见情况编写特殊处理例程

优化效果： - 指令数从3.01亿降至2000万 - 解码时间从70分钟缩短至1分钟 - 最终实现完全用6502汇编编写

项目资源： - 算法演进记录库 - 最终汇编实现（解码器和位缓冲处理）

这个案例展示了在极端硬件限制下，通过算法重构和针对性优化取得的显著性能提升。作者强调，相比单纯的手工汇编优化，算法层面的改进往往能带来更大的收益。

这篇评论总结围绕三个主要观点展开：

1. 对"少做优化"理念的认同

• "Good reminder to do less, rather than the same thing but optimized."（评论1）
• 认为工程师在低抽象环境中实践技艺很"refreshing"（评论3）

2. 技术实现中的异常现象

• 使用特定配置时出现屏幕变色问题："my whole screen change colour...Everything becomes slightly darker"（评论2）

3. 对硬件/软件优化路径的思考

• 认为软件优化潜力被低估："Optimizing software doesn't have the same potential as optimizing hardware but i'd say 1/70 is significant"（评论4）
• 提出另一种发展可能："just write faster software...would have given us really really cheap devices"（评论4）
• 指出当前专用芯片应用有限："those efforts went pretty much nowhere"（评论4）