Eric Wing | 29 Jun 18:51 2015
Picon

JavaScriptCore performance is very slow on Windows

Hi,
I’ve been trying to use JavaScriptCore as an embedded scripting
language for a video game engine. (Note: I am just using JSCore, not
WebKit.) I’ve been using it on multiple platforms. During my testing,
I’ve discovered that the JavaScriptCore Windows performance is very
slow. I wanted to alert you in hopes there is something that can be
done to fix it.

I’ve been getting help on building JavaScriptCore for Windows from a
few people in the community. My current build is as of a couple of
weeks ago. However, I’ve been seeing the same performance
characteristics from a build from a little over a year ago.

To prove to you that this is a problem to just JavaScriptCore on
Windows, and not a general Windows problem, nor a problem with my
code, I have done the following:

- I ran the program on Windows, OS X, Linux, iOS, Android, and
Raspberry Pi (Linux).
- I wrote comparable programs in C and Lua and also ran these on all platforms.
- Additionally, I was able to run on the same hardware (dual boot) for
Windows/Linux.

So here is the quick summary:

                   Ubuntu 12.04 LTS (64-bit)
Windows 8.1 (64-bit)
===========================================================
C                     5600 sprites
         27000 sprites
(Continue reading)

Gary Kratkin | 28 Jun 17:58 2015

JavaScriptCore cross context object sharing

Hello,

The documentation for JSContextGroupCreate states that "Contexts in the same group may share and exchange JavaScript objects.”  How is this done?

For example, given a context A, and a context B created in the same group (using JSGlobalContextCreateInGroup), how can script in B reference A's global object?

This is WebKitGTK, vintage 2.4.7.

Thanks for any guidance,
Gary Kratkin
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Rodney Dowdall | 24 Jun 23:10 2015

JavaScriptCore slowdown

Hello

I have two ports of WebKit.  The first is based off of revision 145828 
and the second is based off of 184845.  I have compiled these ports for 
Linux x86 32 bit.  I would like to know why the port based on revision 
145828 is faster at running the JavaScriptCore tests.  I have the DFG 
JIT enabled for both, and I do not have the FTL JIT turned on (obviously 
because it is not supported for 32  bit builds).  I was wondering if 
maybe I need to enable another setting the 184845 revision, but I think 
I have turned on all of the JavaScriptCore enablements that I can.  I 
can post these if it makes sense for me to do so.  Here are the numbers 
that I am getting from the two builds.  I am just wondering if this is 
what I should expect.

184845 Webkit

Total:          522.9ms +/- 4.3%

3d:            115.8ms +/- 10.2%
    cube:        57.1ms +/- 13.8%
    morph:        26.5ms +/- 10.2%
    raytrace:        32.2ms +/- 4.5%

access:            45.3ms +/- 7.7%
    binary-trees:    6.0 ms +/- 7.9%
    fannkuch:        17.0 ms +/- 10.5%
    nbody:        16.9 ms +/- 8.8%
    nsieve:        5.4 ms +/- 9.3%

bitops:            17.2 ms +/- 12.8%
    3bits-bits-in-byte:    3.6 ms +/- 31.3%
    bits-in-byte:    4.4 ms +/- 15.7%
    bitwise-and:        3.5 ms +/- 14.4%
    nsieve-bits:        5.7 ms +/- 8.5%

controlflow:        6.2 ms +/- 4.9%
    recursive:        6.3 ms +/- 4.9%

crypto:            57.9 ms +/- 4.8%
    aes:            20.6 ms +/- 5.2%
    md5:            23.5 ms +/- 4.8%
    sha1:        13.8 ms +/- 5.3%

date:            61.9 ms +/- 3.5%
    format-tofte:    29.6 ms +/- 3.3%
    format-xparb:    32.3 ms +/- 3.9%

math:            33.4 ms +/- 5.1%
    cordic:        6.4 ms +/- 14.1%
    parial-sums:        22.3 ms +/- 4.5%
    spectral-norm:    4.7 ms +/- 10.3%

regexp:            12.2 ms +/- 3.7%
    dna:            12.2 ms +/- 3.7%

string:            173.0 ms +/- 2.2%
    base64:         13.1 ms +/- 4.8%
    fasta:         32.6 ms +/- 3.3%
    tagcloud:         32.5 ms +/- 3.3%
    unpack-code:         76.3 ms +/- 2.3%
    validate-input        18.5 ms +/- 2.0%

145828 WebKit
Total:            377.0 ms +/- 1.1%

3d:            56.2 ms +/- 3.1%
    cube:        20.7 ms +/- 6.7%
    morph:        15.8 ms +/- 2.9%
    raytrace:        19.7 ms +/- 2.4%

access:            26.3 ms +/- 2.9%
    binary-trees:    2.1 ms +/- 10.8%
    fannkuch:        11.2 ms +/- 5.9%
    nbody:               8.3 ms +/- 4.2%
    nsieve          4.7 ms +/- 14.4%

bitops:            19.3 ms +/- 4.6%
    3bits-bits-in-byte:    2.1 ms +/- 10.8%
    bits-in-byte:    11.2 ms +/- 14.6%
    bitwise-and:        5.1 ms +/- 4.4%
    nsieve-bits:        8.1 ms +/- 2.8%

controlflow:        3.2 ms +/- 9.4%
    recursive:        3.2 ms +/- 9.4%

crypto:            31.2 ms +/- 3.4%
    aes:            14.6 ms +/- 7.4%
    md5:            9.5 ms +/- 4.0%
    sha1:        7.1 ms +/- 3.2%

date:            64.8 ms +/- 3.7%
   format-tofte:        29.4 ms +/- 5.0%
   format-xparb:         35.4 ms +/- 3.2%

math:            39.8 ms +/- 3.8%
    cordic:        5.8 ms +/- 5.2%
    partial-sums:    30.2 ms +/- 4.7%
    spectral-norm:    3.8 ms +/- 14.8%

regexp:            11.6 ms +/- 5.2%
    dns:            11.6 ms +/- 5.2%

string:            124.6 ms +/- 1.8%
    base64:        12.6 ms +/- 6.7%
    fasta:        22.3 ms +/- 6.4%
    tagcloud:        24.8 ms +/- 4.0%
    unpack-code:        49.3 ms +/- 2.75
    validate-input:    15.6 ms +/- 4.4%

Thanks,
Rodney
youenn fablet | 23 Jun 10:40 2015
Picon

WTF and STL

Hi all,

STL classes such as std::function, std::unique_ptr are being used nowadays in WebKit. The STL has some advantages, such as better documentation, being familiar to non-WebKit developers...

I am wondering whether we should and could use more of the STL.
For instance, constructs that I know of such as Vector, Deque, Optional have close counterparts in the STL.

Is there a way to keep all benefits brought by WTF constructs but using their STL counterparts? Are there WTF constructs that can be replaced directly by STL ones? Should we try it?

Also any thoughts on current WTF benefit compared to STL?

Thanks
    y
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Osztrogonác Csaba | 8 Jun 11:12 2015
Picon

build.webkit.org issue

Hi,

it seems build.webkit.org is unavailabe since yesterday 23:13:00 (UTC).
It would be great if somebody can check what happened. Thanks.

br,
Ossy
Yoav Weiss | 29 May 20:23 2015

Content-DPR header

As a first step towards the Client-Hints implementation, I submitted a patch for Content-DPR support.
A discussion followed on the thread, so I'd like to move it to the list, in order for it to get higher exposure.

Content-DPR is an HTTP response header that enables style-agnostic image resizing, by enabling the server to adapt the image's intrinsic size so that layout will not break, even if the image's dimensions are not defined in style.

Opinions welcome! :)
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Matt | 27 May 20:27 2015
Picon

Implementing Media Session API

Hi WebKit Developers!

I plan on implementing the Media Session API in WebKit. The Media Session API provides web developers the ability to respond to media keys on hardware such as keyboards and remote controls. The tentative spec can be found here: https://mediasession.spec.whatwg.org and my work on this will be behind a feature flag.

The main Bugzilla issue tracking the implementation can be found here: https://bugs.webkit.org/show_bug.cgi?id=145411

Thanks,

Matt

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Max Hentschel | 27 May 14:47 2015

JavaScriptCore: Garbage Collector Issue

Hello,

I watched the WWDC 2013 session on integrating JavaScript into native apps and so I implemented a JavaScript library for a Swift iOS app connecting via JavaScriptCore. Although I don’t really know if this mail list is the correct place to ask, I thought I’d give it a shot.
I really liked how easy it was to get Swift to work with JavaScript and vice versa. But I stumbled upon a problem when I was testing the performance of my app. I wrote a XCTest in Xcode which performs multiple calls of the JavaScript library (with loops) but it always stops or freezes after the 292nd call.
I guess that the JavaScriptCore context (or virtual machine) are not deinitialized after the method call was successful. I even tried a manual deinitialize but it still freezes. I looked up the allocations in Instruments and it shows multiple VM: JS garbage collector allocations which are still active in the app.
I wrote a question on StackOverflow with some code examples and the Instruments log:
http://stackoverflow.com/questions/30443993/javascriptcore-on-ios-vm-garbage-collector-not-automatically-emtpying
but I haven’t received a single answer yet. I guess JavaScriptCore on iOS is still something that is not being used very much.

I would be very happy if someone could take a look into my problem and share thoughts on it. This is part of my bachelor thesis so it would really help me a lot.

Thank you in advance and best regards,
Max Hentschel
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Gyuyoung Kim | 20 May 03:31 2015

Support "registerProtocolHandler" in WebKit2

Hello,

I would like to listen what do you think to support 'registerProtocolHandler' in WebKit2.

This feature is to execute web content through registered custom protocol.
- For example, web content can register "mailto" custom protocol using this feature,
    <script>
        navigator.registerProtocolHandler("mailto",
                                          "https://mail.naver.com/",
                                          "Web Mail");
    </script>

    <html>
    <head>
        <title>Web Protocol Handler Sample - Test</title>
    </head>
        <body>
            <p>Send an email : <a href="mailto://">this !</a></p>
        </body>
    </html>

Besides this feature has been supported by Mozilla and Chromium (From Mozilla 3.0, Chromium 13).

The feature is included in the W3C recommendation 28 released on Oct. 2014.

IIRC, some WebKit1 ports supported this feature though, those ports were deprecated. Now WebKit port supports this feature no more.

There is a very old bug to support this feature though, it wasn't maintained so far. Recently I updated it based on latest WebKit.

Feel free to give me any feedback about this feature.

Gyuyoung.
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Osztrogonác Csaba | 18 May 18:03 2015
Picon

*.webkit.org network issues

Hi,

*.webkit.org sites (trac,bugs,build) are extremely slow
from here (Europe/Hungary) and I didn't get any bugzilla
mail 2 days ago, but I should have got many.

Is it a known issue and/or is anybody working on the fix?

br,
Ossy
Michael Catanzaro | 13 May 00:47 2015

CMake dependency bump?

Hi,

For bug #144747 it would be helpful to require CMake 2.8.12, so that I
can use the SYSTEM argument to target_include_directories. Would this
be a problem for anyone (in particular, the EFL port)? It was released
October 2013 and it's present in Ubuntu 14.04.

Thanks,

Michael

Gmane