On 01/06/2016 12:19 PM, Rhialto wrote: > So keeping every step of the way in the StringView realm is definitely > better. Whether the actual string storage is safe in the long term, I > didn't look at, but presumably it is or more things would go wrong > (probably).
Whereas I believe the opposite: every StringView used in the preference code should be replaced with a simple std::string. The performance gained by objects like StringView only apply when taking substrings of large objects or in areas where repeated memory allocation / deallocation show up in profiler results. With small strings which often fit into the short string area creating a new std::string and copying the string content is a very cheap operation. When it comes to memory copies anything that fits into one or even two cache lines can be completed in about 8 CPU cycles using a series of 64-bit/8-byte MOVs. It is the very definition of trivial. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
