================
@@ -663,6 +663,18 @@ bool PythonDictionary::Check(PyObject *py_obj) {
return PyDict_Check(py_obj);
}
+bool PythonDictionary::HasKey(const llvm::Twine &key) const {
----------------
bulbazord wrote:
You could avoid a potential allocation with the creation of the `PythonString`
entirely with a `StringRef` parameter.
Right now, line 669 invokes `key.str()` to create a `std::string` from the
`key` parameter. In the worst case, this is a memory allocation just to give
the `PythonString` constructor a `StringRef`. This doesn't have to be the case
though, because `Twine` has a method to check if it is representable by a
single `StringRef`, and if so, you can use a different method to get that
`StringRef`. That would look something like this pseudocode:
```
if (key is representable as single StringRef)
PythonString key_object(key.GetStringRefRepresentation());
else
PythonString key_object(key.str());
```
But that's just more complicated. If `key` was a `StringRef` parameter, you
could do `PythonString key_object(key);` and have no potential for additional
allocations.
https://github.com/llvm/llvm-project/pull/71260
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
