Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 09, 2013 [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- Paulo |
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp@progtools.org> wrote:
> A bit off-topic, but well worth reading,
>
> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
Thanks for the link. In my experience, mobile networking is slow in general. When I run Speedtest on my phone vs. a laptop sitting right next to it, the phone has a fraction of the bandwidth of the laptop. So there's even more at issue than raw JS performance.
|
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:
> A bit off-topic, but well worth reading,
>
> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
>
> --
> Paulo
I think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
|
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to QAston | On Tuesday, 9 July 2013 at 19:27:22 UTC, QAston wrote:
> On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:
>> A bit off-topic, but well worth reading,
>>
>> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
>>
>> --
>> Paulo
>
> I think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
Nobody uses D on mobile, so it's not very relevant. ;)
If Intel ever makes a comeback on mobile- Samsung is putting x86 chips in their next generation of Galaxy Tab tablets, so it's possible- it might not take much effort to port D/ldc to Android/x86 though, so maybe it will be relevant someday.
Good article, with some good data.
|
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:
> A bit off-topic, but well worth reading,
>
> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
An interesting article, a strong critique of many kinds of garbage collection. Having good enough built-in means to avoid relying on a GC seems quite important to use D where memory is limited.
Bye,
bearophile
|
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Tuesday, 9 July 2013 at 20:02:33 UTC, bearophile wrote:
> On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:
>> A bit off-topic, but well worth reading,
>>
>> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
>
> An interesting article, a strong critique of many kinds of garbage collection. Having good enough built-in means to avoid relying on a GC seems quite important to use D where memory is limited.
It's not just in the limited memory case of mobile devices that GC is a problem. There are a few domains that come to mind where the ability to escape GC and rely on manual memory management is extremely important. While there was some reference made to an approach to allocators in the closing talk of DConf, I haven't seen much discussion of an approach using D's features.
-- Brian
PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design!
|
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On Tue, 09 Jul 2013 20:12:25 +0200
Paulo Pinto <pjmlp@progtools.org> wrote:
> A bit off-topic, but well worth reading,
>
> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
>
> --
> Paulo
Very good article. (Actually, a nice site design, too.)
|
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On 7/9/2013 11:12 AM, Paulo Pinto wrote:
> A bit off-topic, but well worth reading,
>
> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
It isn't off-topic at all. It's very relevant to D.
I also agree with what he says about GC.
|
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright: > It isn't off-topic at all. It's very relevant to D. > > I also agree with what he says about GC. There's a long way from recognizing those problems, to having good enough solutions in D. Some possible attack strategies for D are: - A less allocating Phobos to produce a bit less garbage; - A more precise GC to avoid some memory leaks; - Perhaps an annotation to disallow heap allocations in a function or a piece of code; - Some good way to allocate variable length arrays on the stack (http://d.puremagic.com/issues/show_bug.cgi?id=9832 ) (so some arrays produce no garbage); - The implementation of "scope" maybe helps a bit; - Multiple alias this opens some opportunities to use structs in more places, avoiding some heap allocations. - Currently Phobos Scoped/emplace are not very good. Is that enough? Rust language designers seem to think that's not enough. Opinions are welcome. Bye, bearophile |
July 09, 2013 Re: [OT] Why mobile web apps are slow | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote: > - A less allocating Phobos to produce a bit less garbage; Yes, and options to pass output ranges to more functions too, instead of always returning gc allocated things. > - Perhaps an annotation to disallow heap allocations in a function or a piece of code; I don't think that will often get used, especially when we're already doing @safe pure const static void foo(); as it is. > - Some good way to allocate variable length arrays on the stack (http://d.puremagic.com/issues/show_bug.cgi?id=9832 ) (so some arrays produce no garbage); These might be cool. Something we can do today is use static arrays as buffers. In my non-gc D experiments, I've made great use of a StackArray!(type, max_capacity) with the convenience operators overloaded. Combined with a solid "scope" implementation, this could be fast, convenient, and safe. Of course it would need to have a statically known max length big enough to store what you want to store without being too wasteful. But I don't think that's particularly hard in most cases - at least we have RangeError so it dies gracefully instead of buffer overflowing like you'd get i C. (It could also automatically grow to the gc heap if the programmer is ok with that.) > - The implementation of "scope" maybe helps a bit; Yes. > Is that enough? Rust language designers seem to think that's not enough. Opinions are welcome. I think if we do scope well enough, we'll have something similar to Rust that we can flesh out more in the library. |
Copyright © 1999-2021 by the D Language Foundation