Re: [webkit-dev] Removing webkitSlice (was Re: Existing metrics for deprecated features)

2012-09-14 Thread Pavel Feldman


 By the way, in preparing the patch, I noticed that webkitSlice was
 used by the web inspector.  Note that the data above includes the use
 by the web inspector.


The usage was in the heap profiler's load snapshot routines, so I can
imagine it not being invoked a lot. That matches the stats fine. We'll
follow up on it.

Regards
Pavel


 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Removing webkitSlice (was Re: Existing metrics for deprecated features)

2012-09-14 Thread Adam Barth
On Thu, Sep 13, 2012 at 9:05 PM, Maciej Stachowiak m...@apple.com wrote:
 I wonder also how likely it is that some of the webkitSlice uses are on
 Google-controlled Web properties and therefore could be fixed ahead of time.

I looked using an internal code-search tool, and I couldn't find any
uses of webkitSlice in Google-controlled web properties.  I did find a
handful of Chrome extensions that are using the API, but all but one
of them will work properly after we remove webkitSlice.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Removing webkitSlice (was Re: Existing metrics for deprecated features)

2012-09-13 Thread Adam Barth
On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth aba...@webkit.org wrote:
 Another metric we have is for Blob.webkitSlice:

 Ratio of Blob.webkitSlice calls to Blob.slice: 14.87%
 Ratio of Blob.webkitSlice calls to Document creation: 0.0053%

 It's difficult to know how to interpret this data because we don't
 actually correlate calls to webkitSlice with Documents or Pages.
 Instead, we just count the total number of calls across all Documents.
  This gives us an upper bound on how many Documents (or Pages) would
 be affected by deleting Blob.webkitSlice, but doesn't measure that
 information as accurately as the data we have for mutation events.

Based on this data, I've posted a patch for removing Blob.webkitSlice
in favor of Blob.slice:

https://bugs.webkit.org/show_bug.cgi?id=96715

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Removing webkitSlice (was Re: Existing metrics for deprecated features)

2012-09-13 Thread Darin Fisher
On Thu, Sep 13, 2012 at 6:16 PM, Adam Barth aba...@webkit.org wrote:

 On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth aba...@webkit.org wrote:
  Another metric we have is for Blob.webkitSlice:
 
  Ratio of Blob.webkitSlice calls to Blob.slice: 14.87%
  Ratio of Blob.webkitSlice calls to Document creation: 0.0053%
 
  It's difficult to know how to interpret this data because we don't
  actually correlate calls to webkitSlice with Documents or Pages.
  Instead, we just count the total number of calls across all Documents.
   This gives us an upper bound on how many Documents (or Pages) would
  be affected by deleting Blob.webkitSlice, but doesn't measure that
  information as accurately as the data we have for mutation events.

 Based on this data, I've posted a patch for removing Blob.webkitSlice
 in favor of Blob.slice:

 https://bugs.webkit.org/show_bug.cgi?id=96715

 Adam


So, worst case 53 out of a million pages calls webkitSlice.  But, it is
easy to imagine that that upper bound is crazy high, and more likely a
couple pages simply call webkitSlice a lot.  Also, given that there are so
many more calls to Blob.slice() one could imagine that sites that call
webkitSlice probably have fallback to Blob.slice().  Is this the hypothesis?

-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Removing webkitSlice (was Re: Existing metrics for deprecated features)

2012-09-13 Thread Maciej Stachowiak

On Sep 13, 2012, at 11:15 PM, Darin Fisher da...@google.com wrote:

 
 
 On Thu, Sep 13, 2012 at 6:16 PM, Adam Barth aba...@webkit.org wrote:
 On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth aba...@webkit.org wrote:
  Another metric we have is for Blob.webkitSlice:
 
  Ratio of Blob.webkitSlice calls to Blob.slice: 14.87%
  Ratio of Blob.webkitSlice calls to Document creation: 0.0053%
 
  It's difficult to know how to interpret this data because we don't
  actually correlate calls to webkitSlice with Documents or Pages.
  Instead, we just count the total number of calls across all Documents.
   This gives us an upper bound on how many Documents (or Pages) would
  be affected by deleting Blob.webkitSlice, but doesn't measure that
  information as accurately as the data we have for mutation events.
 
 Based on this data, I've posted a patch for removing Blob.webkitSlice
 in favor of Blob.slice:
 
 https://bugs.webkit.org/show_bug.cgi?id=96715
 
 Adam
 
 So, worst case 53 out of a million pages calls webkitSlice.  But, it is easy 
 to imagine that that upper bound is crazy high, and more likely a couple 
 pages simply call webkitSlice a lot.  Also, given that there are so many more 
 calls to Blob.slice() one could imagine that sites that call webkitSlice 
 probably have fallback to Blob.slice().  Is this the hypothesis?

Adam's data measures webkitSlice() *calls*, not just appearances of the symbol, 
so these are either sites that have fallback in the wrong direction (trying the 
prefixed version before the vanilla version), or would break after the removal. 
I've seen both problems with about similar frequency in the past, so a decent 
hypothesis is that half those webkitSlice calls will break.

Safari hasn't had Blob for very long at all, so Chrome is probably more 
impacted. From my own perspective, I think the usage is low enough that it's 
worth making the change to see the fallout. 

I wonder also how likely it is that some of the webkitSlice uses are on 
Google-controlled Web properties and therefore could be fixed ahead of time.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Removing webkitSlice (was Re: Existing metrics for deprecated features)

2012-09-13 Thread Adam Barth
On Thu, Sep 13, 2012 at 9:05 PM, Maciej Stachowiak m...@apple.com wrote:
 On Sep 13, 2012, at 11:15 PM, Darin Fisher da...@google.com wrote:
 On Thu, Sep 13, 2012 at 6:16 PM, Adam Barth aba...@webkit.org wrote:
 On Thu, Sep 13, 2012 at 5:13 PM, Adam Barth aba...@webkit.org wrote:
  Another metric we have is for Blob.webkitSlice:
 
  Ratio of Blob.webkitSlice calls to Blob.slice: 14.87%
  Ratio of Blob.webkitSlice calls to Document creation: 0.0053%
 
  It's difficult to know how to interpret this data because we don't
  actually correlate calls to webkitSlice with Documents or Pages.
  Instead, we just count the total number of calls across all Documents.
   This gives us an upper bound on how many Documents (or Pages) would
  be affected by deleting Blob.webkitSlice, but doesn't measure that
  information as accurately as the data we have for mutation events.

 Based on this data, I've posted a patch for removing Blob.webkitSlice
 in favor of Blob.slice:

 https://bugs.webkit.org/show_bug.cgi?id=96715

 Adam


 So, worst case 53 out of a million pages calls webkitSlice.  But, it is easy
 to imagine that that upper bound is crazy high, and more likely a couple
 pages simply call webkitSlice a lot.  Also, given that there are so many
 more calls to Blob.slice() one could imagine that sites that call
 webkitSlice probably have fallback to Blob.slice().  Is this the hypothesis?


 Adam's data measures webkitSlice() *calls*, not just appearances of the
 symbol, so these are either sites that have fallback in the wrong direction
 (trying the prefixed version before the vanilla version), or would break
 after the removal. I've seen both problems with about similar frequency in
 the past, so a decent hypothesis is that half those webkitSlice calls will
 break.

 Safari hasn't had Blob for very long at all, so Chrome is probably more
 impacted. From my own perspective, I think the usage is low enough that it's
 worth making the change to see the fallout.

 I wonder also how likely it is that some of the webkitSlice uses are on
 Google-controlled Web properties and therefore could be fixed ahead of time.

By the way, in preparing the patch, I noticed that webkitSlice was
used by the web inspector.  Note that the data above includes the use
by the web inspector.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev