Jump to page: 1 26  
Page
Thread overview
[OT] Why mobile web apps are slow
Jul 09, 2013
Paulo Pinto
Jul 09, 2013
Sean Kelly
Jul 10, 2013
Oleg Kuporosov
Jul 09, 2013
QAston
Jul 09, 2013
Joakim
Jul 10, 2013
Paulo Pinto
Jul 09, 2013
bearophile
Jul 09, 2013
Brian Rogoff
Jul 10, 2013
qznc
Jul 10, 2013
Walter Bright
Jul 10, 2013
Nick Sabalausky
Jul 10, 2013
Walter Bright
Jul 10, 2013
Jonathan A Dunlap
Jul 10, 2013
John Colvin
Jul 10, 2013
H. S. Teoh
Jul 10, 2013
John Colvin
Jul 11, 2013
Jonathan Dunlap
Jul 12, 2013
Peter Alexander
Jul 09, 2013
Nick Sabalausky
Jul 09, 2013
Walter Bright
Jul 09, 2013
bearophile
Jul 09, 2013
Adam D. Ruppe
Jul 10, 2013
H. S. Teoh
Jul 10, 2013
Paulo Pinto
Jul 10, 2013
thedeemon
Jul 10, 2013
bearophile
Jul 10, 2013
Paulo Pinto
Jul 10, 2013
bearophile
Jul 11, 2013
Brian Rogoff
Jul 11, 2013
thedeemon
Jul 11, 2013
bearophile
Jul 11, 2013
Paulo Pinto
Jul 10, 2013
Michel Fortin
Jul 11, 2013
renoX
Jul 11, 2013
deadalnix
Jul 10, 2013
Sean Kelly
Jul 10, 2013
bearophile
Jul 10, 2013
Jacob Carlborg
Jul 10, 2013
Paulo Pinto
Jul 11, 2013
Jacob Carlborg
Jul 11, 2013
Paulo Pinto
Jul 11, 2013
Jacob Carlborg
Jul 14, 2013
SomeDude
Jul 14, 2013
Paulo Pinto
Jul 16, 2013
Sean Kelly
Jul 16, 2013
Paulo Pinto
Jul 16, 2013
Jonathan Dunlap
Jul 16, 2013
Paulo Pinto
Jul 16, 2013
Jonathan A Dunlap
Jul 16, 2013
John Colvin
Jul 17, 2013
deadalnix
Jul 17, 2013
deadalnix
Jul 13, 2013
Kagamin
July 09, 2013
A bit off-topic, but well worth reading,

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

--
Paulo
July 09, 2013
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
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
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
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
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
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
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
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
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.
« First   ‹ Prev
1 2 3 4 5 6