Bug Tracker

Ticket #11989 (closed bug: fixed)

Opened 3 years ago

Last modified 2 years ago

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:
Blocking: Blocked by:

Description (last modified by rwaldron) (diff)

Fragment cache benefits only apply to single element creation, which isn't a realistic representation of real world use cases

Change History

comment:1 Changed 3 years ago by rwaldron

  • Status changed from new to assigned
  • Component changed from unfiled to manipulation
  • Priority changed from undecided to low
  • Version 1.7.2 deleted
  • Milestone changed from None to 1.9
  • Owner set to rwaldron

comment:2 Changed 3 years ago by rwaldron

  • Description modified (diff)
  • Summary changed from Avoid fragment cache in browsers that won't benefit from its use to Investigate fragment cache performance in terms of large html fragments

comment:3 Changed 3 years ago by konp

do some jsPerf tests need to be created to progress on this?

comment:4 Changed 3 years ago by dmethvin

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:  http://jsperf.com/fraggler

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++ )

The paragraph text is fragment-cached so it doesn't have to be re-$.cleaned 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.

comment:5 Changed 3 years ago by dmethvin

  • Owner rwaldron deleted
  • Status changed from assigned to open
  • Milestone changed from 1.9 to 2.0

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.

comment:6 Changed 3 years ago by pbramos

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

Last edited 3 years ago by pbramos (previous) (diff)

comment:7 Changed 3 years ago by pbramos

comment:8 Changed 3 years ago by Paul Ramos

  • Status changed from open to closed
  • Resolution set to fixed

Fix #11989. Remove fragment cache, moving to jquery-compat. Close gh-1052.

Changeset: 13449a99b2b279a7ae6401b8373d20504362213d

comment:9 Changed 2 years ago by dmethvin

  • Milestone changed from 2.0 to 1.9
Note: See TracTickets for help on using tickets.