Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.2.BETA1, 3.2
-
Fix Version/s: EE-3.2.0.BETA, EE-3.2.0.GA, 3.3
-
Component/s: ACE-Components
-
Labels:None
-
Environment:IE8, Firefox
Description
When completing actions of retrieving and clearing an ace:dataTable that co=
ntains an ace:dateTimeEntry component, IE8 browser takes more and more memo=
ry very rapidly.
Here is my testing data with the page displaying 200 rows.
Memory IE process takes after each Retrieve:
110M (baseline), 149, 212, 298, 332, 362, 392, 443, 486, 560, 612=E2=80=A6=
=E2=80=A6
It reaches 1G after 22 Retrieves. The memory size does not go down after I =
stopped performing any action.
This problem does not occur on a page which does not contain calendar widge=
ts in the table. It also occurs in FireFox to a lesser degree. The memory b=
uilds up over time but at a much slower pace. Here is the numbers for FF:
174M, 191, 200, 212, 220, 226=E2=80=A6
This memory leak could be coming from DatePicker plugin under the calendar =
widget. JQuery has an open bug on it: http://bugs.jqueryui.com/ticket/8164.=
This could be contributing to the client-side performance degradation in t=
he application.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
I think the issue is more related to the dateTimeEntry events being registe=
red and never cleared when the dataTable contents are dynamically updated.
=20
Assignee Priority: P1 (was: P2)
Re-opened.
Customer is seeing debilitating performance issues related to the addition =
of this cleanup code.
When used in a dataTable containing 400 instances of the ace:dateTimeEntry,=
the time to run through the cleanup code when the table is removed is addi=
ng 30 seconds to the operation, which is unacceptable to the customer.
Need to analyze what is being done in this cleanup code with a perspective =
on execution efficiency. Also, note that this time is being spent even if =
the user doesn't interact with the components (hence, not initialized fully=
yet due to the recent addition of lazy init to this component). Perhaps cl=
eanup logic is being called that is not necessary if the component hasn't b=
een initialized yet, etc.
=20
Assignee: (was: yip.ng)
Resolution: Fixed
Marking this resolved. If further changes to the memory cleanup for this co=
mponent are required for performance or other reasons, a new JIRA will be u=
sed.
(Restricted to icesoft-internal-developers group)
=20
From link mentioned in Description (http://bugs.jqueryui.com/ticket/8164), =
problem is caused by bindHover(). bindHover() is used to implement CSS chan=
ges when hovering over calendar (e.g. color change when hovering over a day=
). Two suggested fixes from there:
ality
tainer div of calendar)
We have already decided that .live() causes major performance problems and =
is no good? So change to use .on()? But in this scenario there seems not mu=
ch difference .bind() and .on(). Will changing to .on() help?