为什么AWS Lambda运行脚本耗时显著更长？以pandas读取S3固定宽度文件为例

核心原因 #

• 转换器参数配置错误：代码中converters={"Column1": "first_name_substring"}传入的是函数名称字符串，而非函数对象本身。本地运行环境可能因运行时上下文、pandas版本差异凑巧可以定位到对应函数执行，但在Lambda的隔离运行环境中，pandas会对字符串参数做大量无意义的解析判断，甚至触发逐行的字符串匹配 fallback 逻辑，产生百倍级的额外耗时。
• Lambda CPU算力限制：AWS Lambda的CPU算力和分配的内存大小强绑定，仅当内存配置≥1769MB时才能拿到1个完整vCPU，低于该阈值的内存配置仅能获得等比例缩放的CPU算力。扩容三倍内存后性能提升有限，大概率是扩容后的内存仍远低于1769MB阈值，CPU算力没有得到质变提升，而pd.read_fwf属于典型CPU密集型操作，弱算力环境下耗时自然远高于本地PC。
• 逐行处理逻辑开销过大：自定义转换器、超长na_values匹配列表两个配置，都会导致pandas无法调用底层优化的C语言解析路径，只能通过Python解释器逐行执行处理逻辑，在弱CPU环境下开销会被无限放大。

优化方案 #

• 修正转换器配置：将converters={"Column1": "first_name_substring"}改为直接传入函数对象converters={"Column1": first_name_substring}，优先消除参数配置错误带来的无意义开销。
• 调整Lambda资源配置：直接将内存配置提升至2048MB及以上，拿到完整vCPU算力，CPU密集型操作的耗时会随算力提升线性下降。
• 替换逐行处理逻辑：将自定义转换器、NA值匹配逻辑从pd.read_fwf的入参中移除，待全量数据读取为dataframe后，使用pandas向量化操作批量处理，例如用str.split、replace等方法批量处理Column1字段和NA值，完全规避Python逐行执行的开销。
• 可选优化：如果需要进一步提升性能，可以将S3上的固定宽度txt文件提前转换为parquet格式存储，Lambda读取parquet格式文件的速度比解析txt快10倍以上；也可以替换pandas为性能更优的polars库做文件解析。

内容的提问来源于stack exchange，提问作者learner