> If one just makes it faster without major benefits that patch is likely to be rejected IF the project were overwhelmed with incoming patches, then I would ag

> If one just makes it faster without major benefits that patch is likely to be rejected IF the project were overwhelmed with incoming patches, then I would agree that there's probably higher priority changes than optimizing 'yes'. But I'm almost certain the GNU project is not being overwhelmed with changes to the core utilities. Everything else being equal (code quality, readability, test coverage, etc.) there's really no reason to reject a patch that demonstrably improves the project, even in some silly way like making 'yes' really fast.