On Thu, Mar 16, 2017 at 09:17:05AM -0700, Gregory Szorc wrote: > On Thu, Mar 16, 2017 at 7:34 AM, Yuya Nishihara <y...@tcha.org> wrote: > > > On Mon, 13 Mar 2017 22:15:47 -0700, Gregory Szorc wrote: > > > # HG changeset patch > > > # User Gregory Szorc <gregory.sz...@gmail.com> > > > # Date 1489467734 25200 > > > # Mon Mar 13 22:02:14 2017 -0700 > > > # Node ID b4159d4c3683f03b6962991f318b080d849d6ba3 > > > # Parent d600bd4edd62b3ee74730f1282e53b9d596bbaec > > > [RFC] parsers: create a dedicated type for an obs marker > > > > I haven't reviewed these carefully, but I like the direction. > > fm1readmarkers() > > creates a bunch of boxed objects, which would have somewhat significant > > cost. > > > > Can we split obsmarker handling to new module? It's getting bigger. > > > > Yes, I was considering that. > > But instead of creating N+1 Python modules, I'd like to move us in the > direction of a single module built from multiple .c files. This is the > approach I've taken in python-zstandard, for example. I believe this > approach is superior because having a single compilation unit facilitates > code reuse, inlining between source files, smaller binaries, and better > performance. >
+1 for multiple .c files that compile into parsers.so for this. Also, making a type in C is probably unambiguously the right thing for handling our data formats anyplace it's viable, for exactly this reason. > _______________________________________________ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
