On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > BTW, while we're thinking about marginal improvements: instead of > constructing the string backwards and then reversing it in-place, > what about building it working backwards from the end of the buffer > and then memmove'ing it down to the start of the buffer? > > I haven't tested this but it seems likely to be roughly a wash > speed-wise. The reason I find the idea attractive is that it will > immediately expose any caller that is providing a buffer shorter > than the required length, whereas now such callers will appear to > work fine if they're only tested on small values. > > A small downside is that pg_itoa would then need its own implementation > instead of just punting to pg_ltoa.
I think that might be more clever than is really warranted. I get your point about buffer overrun, but I don't think it's that hard for callers to do the right thing, so I'm inclined to think that's not worth much in this case. Of course, if memmove() can be implemented as a single assembler instruction or something, that might be appealing from a speed standpoint, but otherwise I think we may as well stick with this. There's less chance of needlessly touching an extra cache line, less chance of being confused by leftover garbage in memory after the end of the output string, and less duplicate code. I had given some thought to whether it might make sense to try to figure out how long the string will be before we actually start generating it, so that we can just start in the exactly right space and have to clean up afterward. But the obvious implementation seems like it could be more expensive than just doing the copy. -- 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
