Hi, On Sun, Dec 14, 2025 at 12:09:08PM +0100, Daniel Stenberg via curl-library wrote: > When a user sets a URL in libcurl it allows up to an 8 megabyte string. If > that URL uses a maximum amount of "../" occurances, all those need to be > "optimized away" in the dotdot normalization phase of the URL parsing. > > That makes 2,666,663 three-byte sequences to remove in the worst possible > case.
... > Thoughts? Hopefully curl is not implementing various string activity areas as *in-place* string data replace activity (CPU cache adventures), but rather as properly distinct (in-out data handling properly fully separated) activity. (can make a performance difference to the tune of e.g. a factor of a whopping 1000something with multi-MBs strings *), from own experience). *) due to permanent *in-place re-writing* of multi-MBs of string data (e.g. by iteratively removing few "victim" bytes each in the *middle* of MB-sized data) I've now had a short look at CURL sources, and dedotdotify() does seem to have some (limited?) semi-mixed handling (does apply some string truncation etc. to out-side allocation **)). **) this would not be the case with fully cleanly separated parser <-> generator (in / out) handling (though such clean handling may easily be overkill in any rather "simple" situations) Greetings Andreas Mohr -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
