Side navigation
#11989 closed bug (fixed)
Opened June 28, 2012 07:01PM UTC
Closed December 05, 2012 02:33AM UTC
Last modified January 15, 2013 03:18AM UTC
Investigate fragment cache performance in terms of large html fragments
Reported by: | rwaldron | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | 1.9 |
Component: | manipulation | Version: | |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Fragment cache benefits only apply to single element creation, which isn't a realistic representation of real world use cases
Attachments (0)
Change History (9)
Changed June 28, 2012 07:01PM UTC by comment:1
component: | unfiled → manipulation |
---|---|
milestone: | None → 1.9 |
owner: | → rwaldron |
priority: | undecided → low |
status: | new → assigned |
version: | 1.7.2 |
Changed June 28, 2012 07:05PM UTC by comment:2
description: | There may be performance wins here, I'm going to investigate → Fragment cache benefits only apply to single element creation, which isn't a realistic representation of real world use cases |
---|---|
summary: | Avoid fragment cache in browsers that won't benefit from its use → Investigate fragment cache performance in terms of large html fragments |
Changed September 05, 2012 07:39AM UTC by comment:3
do some jsPerf tests need to be created to progress on this?
Changed September 05, 2012 01:03PM UTC by comment:4
I suspect that most real jQuery code doesn't benefit from the fragment cache very much anymore. Here is what I came up with, but perhaps I've got something wrong in there:
It definitely helps in browsers like IE6/7, where there was code like this in a circa-2008 benchmark:
for ( var i=0; i < 10000; i++ ) $("body").append("<p>paragraph</p>");
The paragraph text is fragment-cached so it doesn't have to be re-$.clean
ed each time through the loop. Note that any loop that inserts a lot of *unique* content each time through the loop does not benefit at all from the cache, and in fact is slower/bigger because of it:
for ( var i=0; i < 10000; i++ ) $("body").append("<p>paragraph number "+i+"</p>");
Since the fragment cache doesn't save anything larger than 512 bytes, it doesn't have any effect on large fragments by design. It seems unlikely that someone would be inserting huge identical fragments of HTML anyway.
So I'd be interested in finding real-world cases where performance is badly affected by just pulling all the frag cache stuff out. Seems like oldIE is the most likely casualty there, so if there are such cases perhaps we'll need to yank it in 2.0 and not 1.9.
Changed November 02, 2012 02:58AM UTC by comment:5
milestone: | 1.9 → 2.0 |
---|---|
owner: | rwaldron |
status: | assigned → open |
I don't think we should tackle this until 2.0, yanking out the frag cache is probably more disruption than we want to do.
Changed December 02, 2012 11:23PM UTC by comment:6
_comment0: | The decision to remove fragment cache has been made, and since fragment cache will need some addressing with a fix I have for #4087 I volunteered to do the honors. \ \ See: \ #4087 - http://bugs.jquery.com/ticket/4087 \ Pull request for #4087 - https://github.com/jquery/jquery/pull/1047#discussion_r2284505 → 1354490622357487 |
---|
The decision to remove fragment cache has been made, and since fragment cache will need some addressing with a fix I have for #4087 I volunteered to do the honors.
See:
Pull request for #4087 - https://github.com/jquery/jquery/pull/1047#discussion_r2284505
Changed December 03, 2012 01:17AM UTC by comment:7
Pull request https://github.com/jquery/jquery/pull/1052
Changed December 05, 2012 02:33AM UTC by comment:8
resolution: | → fixed |
---|---|
status: | open → closed |
Fix #11989. Remove fragment cache, moving to jquery-compat. Close gh-1052.
Changeset: 13449a99b2b279a7ae6401b8373d20504362213d
Changed January 15, 2013 03:18AM UTC by comment:9
milestone: | 2.0 → 1.9 |
---|