On Tue, Feb 19, 2008 at 01:29:50PM -0500, Loui wrote:

On Tue, Feb 19, 2008 at 12:11 PM, eliott wrote:

...

Your patch adds a needless string concatenation operation, for the sole sake of a line break. Not a good idea. String concatenation adds up, peformance wise.

Sorry I wasn't aware of that. I really hate the long lines though. It's a lot easier to work with code that fits neatly within a certain number of columns (for me). Even with the performance hit I'd probably still go for it. I bet there's a lot of other places that performance can be improved.

I've just read something about an output buffer that sounds like it might increase performance for all output strings. Should we go about using that in the rest of the code where applicable?

I'm pretty sure eliott wants to uber-optimize the json interface because it's very possible that this code will get hit more frequently than any other aur code. Generally though, I don't really see anything wrong with string concatenation, espcially if it enhances readability (which php tends to lack sometimes imho). Patch applied, without string concatenation :) zoom zoom -S

On Wed, Feb 20, 2008 at 03:26:06PM -0500, Loui wrote:

On 2/20/08, Simo Leone wrote:

...

I'm pretty sure eliott wants to uber-optimize the json interface because it's very possible that this code will get hit more frequently than any other aur code. Generally though, I don't really see anything wrong with string concatenation, espcially if it enhances readability (which php tends to lack sometimes imho).

Patch applied, without string concatenation

:) zoom zoom

Alrighty good stuff. That line that I did the string concatenation actually had a valid fix though :P the space after AND at the end of the string is required. Either that, or a space before "Name=" further down in the code.

hehehe, wow I missed that, I totally looked. Fixed in testing though, and some git magic says you fixed it :) -S