Re: [PHP-DEV] [RFC] Working With Substrings
Hi Derick, Thomas, Op do 16 feb. 2023 om 08:57 schreef Derick Rethans : > > > https://wiki.php.net/rfc/unicode_text_processing > > And yes, that won't be as fast as just calling strtoupper. > > cheers > Derick > Looks great!!! Complex string manipulation inside an object will be faster then all copying variables around in memory, like Thomas kindly explained in his post. If I understand correctly And it would make php even more mature, gaining from more OOP. Op wo 15 feb. 2023 om 20:35 schreef Thomas Hruska : > <..> Doing that operation one time is fast enough and not really a problem. > Doing it 1,000,000 times in a loop is where we end up constantly copying > memory around when we could potentially work on the same memory buffer > the entire time. We still might end up using the same memory buffers > over and over due to recycling them through the PHP memory pool, which > means the buffers might get to sit in the L1 or L2 cache in the CPU, but > it does leave some performance on the table because copying a buffer or > portions of it repeatedly can be an unnecessary operation. Buffers that > are larger than the CPU's cache line sizes are going to suffer the most > because there will be constant requests to main memory for the > information that the CPU needs to modify and will constantly flush the > cache lines and stall out while waiting for more data to arrive. That's > not exactly optimal/ideal. Modifying the same buffer inline will be > more likely stay in the L1 and L2 cache lines and therefore be much > closer to the CPU core, resulting in notably faster performance. > Pointers in C are much faster than copying memory. The problem is > exposing pointers to userland, especially in Internet-facing software. > Pointers are notoriously unsafe - just look at the zillion buffer > overflow vulnerabilities (CVEs) that are reported annually across all > software products. Copy-on-write, by comparison, is a much safer > operation at the cost of performance. However, pointers let us just > point at a substring or general chunk of memory instead of copying it, > which significantly reduces the overhead since pointers are simple > integer values that contain a memory address. And those values are > small enough to sit in CPU registers, which are blazing fast. CPUs only > have a handful of registers though because each register dramatically > increases the cost of the CPU die. So if we can just point at the memory we want to "extract" instead of actually copying the data into > its own string object, we can potentially save a ton of CPU cycles, > especially when working with data inside a loop. > > > Overall, I think substrings offer the most obvious/apparent area for > performance gains and probably have, implementation details aside, the > least amount of friction. But maybe we should consider the larger > ecosystem of string functions as well? Or should this just be a > possible longer term idea that requires more thought and research and > thus the scope should be limited and we put Lydia's idea under Future > Scope in the RFC? Other thoughts/comments? > > Added as Open Issue 10 to the RFC. Thank you for your input. > > Thomas Hruska > Thanks for your kind and extended explanation. I know a little about the memory allocations. But I am not sure about what to conclude from your explanation. If an object would take less copying around or not. This memory conversation brings up other old memories ☺... peek, pook, assembly etc Greetz, flexJoly (aka Lydia)
Re: [PHP-DEV] include cleanup RFC declined
On 2023/02/16 08:59, Derick Rethans wrote: > Secondary votes are irrelevant if the primary one doesn't pass. You may be formally correct (or maybe not, because https://wiki.php.net/rfc/voting doesn't really say that). In any case, a vote that reaches supermajority (i.e. it would have been accepted if it had been a separate RFC) is an unambiguous expression on how the community wants the PHP source code to look like. It is safe to say that the PHP community doesn't want any include comments and forward declarations, but wants to split large headers in order to reduce header dependencies. I guess we both don't like the outcome of the vote (for different reasons), but let's not start lawyering pointlessly, and accept the community's will. Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] include cleanup RFC declined
Hi On 2/16/23 09:28, Max Kellermann wrote: Secondary votes are irrelevant if the primary one doesn't pass. You may be formally correct (or maybe not, because https://wiki.php.net/rfc/voting doesn't really say that). In any case, a vote that reaches supermajority (i.e. it would have been accepted if it had been a separate RFC) is an unambiguous expression on how the community wants the PHP source code to look like. Not necessarily. It might've been the case that a voter believes that include cleanups should not happen, but at the same time believes that *if* cleanups happen, then splitting a header is a natural part of such a cleanup. The same is true for the secondary vote of the include comments. My understanding is that the primary concern of the "no" votes is the churn in the code base. Removing the existing include comments will just create additional churn and provide no value-add at all. It is perfectly possible to be both against "include comments" and "actively remove include comments". That said I can only summarize the entire RFC, vote and result as "unfortunate". As I've said in my previous email from Feb 9, as a maintainer I'm not sure what a "declined vote" effectively means for me, because the RFC text and vote description is pretty broad and unspecific. May I perform a scoped clean up within a single extension (ext/random in my case)? May I not? Do I need an explicit RFC? I feel like the vote actually made the situation less clear for me. Without this RFC I might've just proposed a PR in the future, made sure to check that I don't unnecessarily break compatibility, requested two or three reviews and it would likely have been approved, merged and shipped with whatever version comes next. Now it is much less obvious what to do or not to do. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] include cleanup RFC declined
On 2023/02/16 17:52, Tim Düsterhus wrote: > Not necessarily. It might've been the case that a voter believes that > include cleanups should not happen, but at the same time believes that *if* > cleanups happen, then splitting a header is a natural part of such a > cleanup. Maybe, but that seems unlikely to me. 1. There is exactly one person who voted "NO" to the primary vote but "YES" to splitting headers. 2. If include cleanups happen, then splitting headers is the only proposed change that is likely to ever cause a merge conflict. If somebody fears "code churn", it wouldn't make sense to accept splitting headers as "natural part". I trust that the voters knew what they were voting for, and if there's a supermajority for splitting headers, then that's the will of the community. > It is perfectly possible to be both against "include comments" and > "actively remove include comments". What you're replying to is just explaining why I believe the secondary votes are not "irrelevant". Your reply doesn't disagree with that, it only speculates how some hypothetical reviewer could reasonably argue to reject PR 10472. That misses the point I tried to make, and I'd rather wait for those hypothetical reviewers to post actual reviews. There hasn't been any so far, even though I posted the PR before voting even began. > I feel like the vote actually made the situation less clear for me. Yes, I feel the same. Requiring a supermajority for this kind of decision doesn't appear to make sense. For some intrusive changes, requiring a supermajority makes sense (if there are serious downsides for the "losing" minority), but IMO not here. The downsides are as minimal as they can be. We're now in a situation where the majority of voters want the code cleanup, but the fact that I asked for the vote made it LESS likely that the majority gets what they want. That is backwards! The cast of a vote must never worsen the situation for the majority. Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
