Thanks for the feedback, and sorry about the slow response.
After some internal discussions, it looks like we are not going to go
forward with this approach at the moment.
cheers,
pl
On 24 February 2016 at 11:16, Tamas Berghammer via lldb-dev
wrote:
> I completely agree with you that we shoul
I completely agree with you that we shouldn't change LLDB too much just to
speed up the startup time at the first use.
For android we already have a host side disk cache in place similar to what
you described for iOS and we already using ADB (an android specific
interface) to download the files fr
> On Feb 23, 2016, at 10:31 AM, Nico Weber wrote:
>
> On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev
> wrote:
> Yes we already have a disk cache on the host. I agree with you that waiting
> 30s at the first startup shouldn't be an issue in general (Pavel isn't
> sharing my opi
On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Yes we already have a disk cache on the host. I agree with you that
> waiting 30s at the first startup shouldn't be an issue in general (Pavel
> isn't sharing my opinion). The only catch is that in c
For progress purposes in Android Studio we listen on
eBroadcastBitModulesLoaded coming from the target so we can report about
every loaded SO.
On Tue, Feb 23, 2016 at 10:00 AM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I believe this is already done.
>
> I am guessing the main
Yes we already have a disk cache on the host. I agree with you that waiting
30s at the first startup shouldn't be an issue in general (Pavel isn't
sharing my opinion). The only catch is that in case of iOS there are only a
few different builds released so if you downloaded the modules once then I
t
I believe this is already done.
I am guessing the main issue is this happens on the first time you debug to a
device you and up with a 30 second delay with no feedback as to what is going
on. So you say "launch" and then 35 seconds later you hit your breakpoint at
main. In Xcode we solve this b
Can't you just cache the modules locally on the disk, so that you only take
that 26 second hit the first time you try to download that module, and then
it indexes it by some sort of hash. Then instead of just downloading it,
you check the local cache first and only download if it's not there.
If
> On Jan 28, 2016, at 4:21 AM, Pavel Labath wrote:
>
> Hello all,
>
> we are running into limitations of the current module download/caching
> system. A simple android application can link to about 46 megabytes
> worth of modules, and downloading that with our current transfer rates
> takes abo
Hello all,
we are running into limitations of the current module download/caching
system. A simple android application can link to about 46 megabytes
worth of modules, and downloading that with our current transfer rates
takes about 25 seconds. Much of the data we download this way is never
actual
10 matches
Mail list logo
