mail
mail copied to clipboard
[port] use ragel-bitmap for less memory
port of #1623
/cc @ahorek
@ahorek it seems received_parser.rb was unchanged in the ragel-bitmap PR. This makes sense as the timestamps of the rl-files hadn't changed.
Manually deleting lib/mail/parsers/*.rb and re-running rake ragel:generate revealed it.
Could you approve this PR so it can be merged? I'll add the extra commit to 2-8-stable. To clean up these files I created #1626 - review welcome as well 🙏🏻
Nicely spotted! Thanks for catching that.
The approval needs to be from someone with commit rights, it seems... mind to help out with this ported PR @sebbASF ?
Sorry, but I'm not convinced that this is a worthwhile change. Whilst the code may be a bit smaller, it complicates the build process, and may result in stale source.
@sebbASF how would you suggest to move fw?
Is there really a need to change?
Compared to other dependencies, this gem has a disproportionately large memory footprint for a simple email parser. This is primarily because Ragel doesn’t generate efficient code for Ruby, and Ruby doesn’t handle large numeric arrays optimally.
https://github.com/mikel/mail/issues/1342 cc @schneems @kddnewton
I don’t believe this complicates the build process. Modifying the Ragel sources requires recompilation regardless, and there’s already a rufo formatter in place. Additionally, the parsers were last updated in 2017, so this change shouldn’t increase maintenance costs.
I think this would be a worthwhile change, but ultimately I wouldn't be the one maintaining it so I don't think I can weigh in very heavily. I believe the memory savings are good, but if it's too complicated to understand maybe it's not worth it.
I think the addition of benchmarks in this PR would be a worthwhile addition, either in the original PR description or as a comment here. Show us your data :)
This may have already been merged in #1623.
It was only merged into the 2.8 branch except for https://github.com/mikel/mail/pull/1630 If you intend to merge 2.8 into master manually, this PR may not be needed.