On Fri, Nov 19, 2010 at 4:16 PM, Andres Freund <and...@anarazel.de> wrote: > On Monday 15 November 2010 17:12:25 Robert Haas wrote:> I notice that int8out > isn't terribly consistent with int2out and >> int4out, in that it does an extra copy. Maybe that's justified given >> the greater potential memory wastage, but I'm not certain. One >> approach might be to pick some threshold value and allocate a buffer >> in one of two sizes based on how large the value is relative to that >> cutoff. But that might also be a stupid idea, not sure. > I removed the extra buffer - its actually a tiny bit faster without it (I > guess the allocation pattern is a bit nicer during copy as it will always take > the same paths and eventually the same address). > I couldn't measure any difference memory-usage wise. > > The code was that way before btw.
Yeah, I know. After further thought I decided not to commit this part, because using 32 bytes when you only need 8 is sort of sucky. I'm not sure if it matters in real life, but if it's only a tiny speedup I guess I might as well play it safe. >> It would speed things up for me if you or someone else could take a >> quick pass over what remains here and fix the formatting and >> whitespace to be consistent with our general project style, and make >> the comment headers more consistent among the functions being >> added/modified. > I think I did most of those - the function comments in numutils weren't > consistent before - now its consistent with the unchanged pg_atoi. > > Thanks for reviewing/applying the first part, Sure thing. Thanks for taking time to do this - very nice speedup. This part now committed, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
