#2 is preferred. When you do it, make sure to add lldb-commits in the
subscribers field. You're also free to add specific people to the
reviewers field, but the mailing list specifically has to be on
subscribers. Unfortunately, due to what I assume are bugs in Phabricator,
if you don't get the s
What's the preferred way to post changes? In the past I tried emailing
here but it was pointed out I should send to lldb-commit instead. But,
there's also phabricator for web-based code reviews.
So,
1. just email lldb-commits?
2. post on http://reviews.llvm.org/?
On Thu, Apr 20, 2017 at 3:16 A
Thank you very much for tracking this down.
+1 for making UniqueCStringMap speak ConstString -- i think it just makes
sense given that it already has "unique" in the name.
ConstString already has a GetStringRef accessor. Also adding a conversion
operator may be a good idea, although it probably w
It doesn't entirely defeat the purpose, it's just not *as good* as making
the interfaces take ConstStrings. StringRef already has a lot of safety
and usability improvements over raw char pointers, and those improvements
don't disappear just because you aren't using ConstString. Although I
agree t
If I just assume the pointers are from ConstString, then doesn't that
defeat the purpose of making the interface safer? Why not use an actual
ConstString and provide conversion operators from ConstString to
StringRef? Seems we should be able to rely on the type system to get us
safety and perform
The change was made to make the interface safer and allow propagation of
StringRef through other layers. The previous code was already taking a
const char *, and so it was working under the assumption that the const
char* passed in came from a ConstString. As such, continuing to make that
same as
It looks like it was this change:
commit 45fb8d00309586c3f7027f66f9f8a0b56bf1cc4a
Author: Zachary Turner
Date: Thu Oct 6 21:22:44 2016 +
Convert UniqueCStringMap to use StringRef.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@283494
91177308-0d34-0410-b5e6-96231b3b80d8
Bisecting the performance regression would be extremely valuable. If you
want to do that, it would be very appreciated.
On 12 April 2017 at 20:39, Scott Smith via lldb-dev wrote:
> For my app I think it's largely parsing debug symbols tables for shared
> libraries. My main performance improveme
For my app I think it's largely parsing debug symbols tables for shared
libraries. My main performance improvement was to increase the parallelism
of parsing that information.
Funny, gdb/gold has a similar accelerator table (created when you link with
-gdb-index). I assume lldb doesn't know how
I don't know exactly when the 3.9 / 4.0 branches were cut, and what was done
between those two points, but in general we don't expect/want to see
performance regressions like that. I'm more familiar with the perf
characteristics on macos, Linux is different in some important regards, so I
can
10 matches
Mail list logo
