3 ms·

I feel like you're giving a very one-sided representation of the issue. There were some very real concerns about the memory usage of the proposed modifications

by nikic 12y ago

I feel like you're giving a very one-sided representation of the issue. There were some very real concerns about the memory usage of the proposed modifications to phpng (you can see http://news.php.net/php.internals/74284 http://news.php.net/php.internals/74284 for an analysis) - what should have happened is that we just went over those changes and decided which parts are feasible and which are not. This happened eventually and now there's a full consensus on how this change is supposed to be implemented (64bit on LLP64, size_t string lengths, uint32_t array lengths). However before that happened the whole discussion was basically a pissing context between Pierre and Zeev. Pierre was most certainly not the one who got us back to cooperating.

CHY872 12y ago
I don't think so. Pierre worked on this in the open, whilst the phpng team did their work in secret. That makes it at least inconsiderate of them that Pierre was not told that the changes might break optimisations in phpng - there should have been a clear communication from them that major changes were coming to php which would affect the utility of his work, and that he should consider holding off. Then, the arguments made in the discussions were basically besides the point. Overall memory usage is not really important on modern hardware, since memory is cheap. The real concerns are time performance - if the performance is degraded, it would be a valid reason to reject some of the changes. The vast majority of criticisms were just along the lines of 'but why do we even need 4GB+ strings' - I can see exactly why Pierre would get frustrated at having to parrot the same line. Performance in current php was clearly fine, and performance in phpng was only ever mentioned in completely vague terms - the most empirical it got was 'i guess 20-30% worse' which isn't really a trustworthy figure by any means. The burden there was up to the phpng team to recognise that there were changes in the standard php pipeline that would potentially invalidate some optimisations. Coming in at a late stage and saying that it would ruin everything, having made no effort to stop someone wasting much time, was at least inconsiderate and probably rude also. Then attempting to effectively filibuster the situation by repeatedly firing irrelevant arguments at Pierre, then recruiting randoms to try and vote against it as some kind of 'we are being undermined' campaign, then trying to change the voting rules, it all just smacked of a very amateurish and/or rude community. Yes, they were mostly by the same people, but at some point someone could have very easily come out and pointed out (for example) the inherent fallacy in the 4GB+ argument, or the fact that the phpng developers should have informed Pierre earlier that their new optimisations might conflict. It seemed like a number were happy letting some fight their preferred argument with the wrong reasons. The arguments of 'wasted data' aren't convincing - the arguments of 'wasted data causes poor performance' would be convincing were there any data whatsoever to back it up, and if those who argued actually worked from that standpoint. My problem was (as someone who read the mailing list) was simply that the very real concerns were brushed under the carpet, and that the situation was allowed to develop in the first place.

by nikic 12y ago

CHY872 12y ago

I don't think so. Pierre worked on this in the open, whilst the phpng team did their work in secret. That makes it at least inconsiderate of them that Pierre was not told that the changes might break optimisations in phpng - there should have been a clear communication from them that major changes were coming to php which would affect the utility of his work, and that he should consider holding off. Then, the arguments made in the discussions were basically besides the point. Overall memory usage is not really important on modern hardware, since memory is cheap. The real concerns are time performance - if the performance is degraded, it would be a valid reason to reject some of the changes. The vast majority of criticisms were just along the lines of 'but why do we even need 4GB+ strings' - I can see exactly why Pierre would get frustrated at having to parrot the same line. Performance in current php was clearly fine, and performance in phpng was only ever mentioned in completely vague terms - the most empirical it got was 'i guess 20-30% worse' which isn't really a trustworthy figure by any means. The burden there was up to the phpng team to recognise that there were changes in the standard php pipeline that would potentially invalidate some optimisations. Coming in at a late stage and saying that it would ruin everything, having made no effort to stop someone wasting much time, was at least inconsiderate and probably rude also. Then attempting to effectively filibuster the situation by repeatedly firing irrelevant arguments at Pierre, then recruiting randoms to try and vote against it as some kind of 'we are being undermined' campaign, then trying to change the voting rules, it all just smacked of a very amateurish and/or rude community. Yes, they were mostly by the same people, but at some point someone could have very easily come out and pointed out (for example) the inherent fallacy in the 4GB+ argument, or the fact that the phpng developers should have informed Pierre earlier that their new optimisations might conflict. It seemed like a number were happy letting some fight their preferred argument with the wrong reasons. The arguments of 'wasted data' aren't convincing - the arguments of 'wasted data causes poor performance' would be convincing were there any data whatsoever to back it up, and if those who argued actually worked from that standpoint. My problem was (as someone who read the mailing list) was simply that the very real concerns were brushed under the carpet, and that the situation was allowed to develop in the first place.