Opened 12 years ago
Closed 10 years ago
#10426 closed feature (notabug)
Meta: Use createContextualFragment to speed up element creation
| Reported by: | Rick Waldron | Owned by: | Rick Waldron |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | manipulation | Version: | 1.7b1 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Recently, Yehuda Katz presented this idea to both us and then the entire jQuery Boston Conference. I think it's worth (at very least) an exploratory implementation to measure performance against.
I'm going to suggest that we work on this between now and 1.8 release
Change History (5)
comment:1 Changed 12 years ago by
| Component: | unfiled → manipulation |
|---|---|
| Milestone: | None → 1.8 |
| Owner: | set to Rick Waldron |
| Priority: | undecided → low |
| Status: | new → assigned |
comment:2 Changed 11 years ago by
comment:3 Changed 11 years ago by
| Milestone: | 1.8 → 1.next |
|---|
comment:4 Changed 11 years ago by
| Type: | enhancement → feature |
|---|
Bulk change from enhancement to feature.
comment:5 Changed 10 years ago by
| Resolution: | → notabug |
|---|---|
| Status: | assigned → closed |
I'll take my advice above and close this until someone shows it really helps. Based on the work orkel did on #10515 I have my doubts.
Note: See
TracTickets for help on using
tickets.
These kind of tickets are pretty ethereal; similar to #10515.
If we can do something here, great, if not let's close it and it will come up organically when someone yells at us for being stupid and not using them.
I am not convinced the fragment cache complexity is worthwhile, perhaps it could be swapped out for code that used
cCForiAH. The primary benefit of the frag cache is that it made us look really good on benchmarks like TaskSpeed circa 2008, but anyone writing production code like that deserves to have bad performance.