labath abandoned this revision.
labath added a comment.
I am abandoning this for the time being in favour of
https://reviews.llvm.org/D24236. The actual implementation of it turned out to
be more hackish then I anticipated.
https://reviews.llvm.org/D22914
___
labath added a comment.
In https://reviews.llvm.org/D22914#511294, @clayborg wrote:
> OK. I can't complain if it doesn't affect performance and could allow
> multiple packets to be in flight with threading, though I think solving this
> issue with threading is a bit of a hack, but it should wor
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
OK. I can't complain if it doesn't affect performance and could allow multiple
packets to be in flight with threading, though I think solving this issue with
threading is a bit of a hack,
labath updated this revision to Diff 67507.
labath added a comment.
The patch I used to run the tests. Still very much WIP.
https://reviews.llvm.org/D22914
Files:
source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
source/Plugi
labath added a comment.
In https://reviews.llvm.org/D22914#510084, @clayborg wrote:
> Let me know how things look on Mac. Our lock primitives are not as fast as
> linux. If all looks good on Mac speed wise, we should be good to go.
These are the results on Mac. Before:
Testing sending 1000
clayborg added a comment.
Let me know how things look on Mac. Our lock primitives are not as fast as
linux. If all looks good on Mac speed wise, we should be good to go.
https://reviews.llvm.org/D22914
___
lldb-commits mailing list
lldb-commits@lis
labath added a comment.
These are the results before and after applying this change (on linux):
Before:
(lldb) process plugin packet speed-test
Testing sending 1000 packets of various sizes:
qSpeedTest(send=0 , recv=0 ) in 0.057456000 sec for 17404.62
packets/sec ( 0.057456 ms
clayborg added a comment.
One thing that should be tested before we go farther, can you check the packet
speed test with and without this patch? We really need to make sure this
doesn't regress. Adding thread synchronization above and beyond taking a mutex
could really impact performance.
Just
clayborg added a comment.
I was out on vacation, sorry for the delay. I will get back to you later today.
https://reviews.llvm.org/D22914
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-c
labath added a comment.
Any thoughts on this, Greg?
https://reviews.llvm.org/D22914
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath added a comment.
I am going to put my responses inilne:
In https://reviews.llvm.org/D22914#499519, @clayborg wrote:
> A few things that worry me:
>
> - There are no sequence IDs on any packets so when receiving responses, I am
> not sure how you are going to match up packets with their r
clayborg added a comment.
A few things that worry me:
- There are no sequence IDs on any packets so when receiving responses, I am
not sure how you are going to match up packets with their responses especially
when you are sending from multiple threads. I didn't look through your
implementatio
labath created this revision.
labath added a reviewer: clayborg.
labath added a subscriber: lldb-commits.
Herald added subscribers: danalbert, tberghammer.
This change adds the ability to the client to send multiple packets without
waiting for the
response to the first one. The individual senders
13 matches
Mail list logo
