[Guido] > First decide what's worse -- overallocating memory or slowing down. > This is not at all clear! If the normal use case is that strings to > be encoded are significantly smaller than memory, overallocating is > worth it. If we expect this to happen for strings close to the VM > size, overallocating may cause problems. I'd be surprised if people are slinging individual multi-hundred megabyte Unicode strings. Martin's timing program went up to 10K characters/string max. Then again, I'm surprised when anyone slings a Unicode string, regardless of size <wink>. > Does Linux still have the problem that its malloc() will let you > allocate more memory than the system has available, and then crash > hard when you try to touch all of it? Apparently so, and apparently the memory characteristics of popular applications running on large servers are such that Linux wouldn't be usable in that market without overcommitment. Or so some people say. A google search turns up many inflamed arguments.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4