Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 170326

Summary:

[regresion] the log view queries the data 3 times from the model for each page load

Product:

z_Archived

Reporter:

Marius Slavescu <slavescu>

Component:

TPTP

Assignee:

Eugene Chan <ewchan>

Status:

CLOSED FIXED

QA Contact:

Severity:

critical

Priority:

CC:

jkubasta, stephen.francisco, zung

Version:

unspecified

Keywords:

plan

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

closed460

Attachments:

Description	Flags
patch	none

Description Marius Slavescu

2007-01-12 11:34:15 EST

This basically decreases the performance almost 3 times.

In the large log case this is amplified because the initial load is much longer than the page by page navigation, so adding that initial load time at each page load gives us much worse performance that the infrastructure is able to support.

If I remember correctly this worked fine in 4.2, I think something happened in 4.2.1. The fix might be just to revert to the 4.2 version.

The same problem is in 4.3.

Comment 1 Eugene Chan

2007-01-12 15:03:23 EST

Need investigation for a target.

Marius, can you give more information for your findings?

Comment 2 Marius Slavescu

2007-01-15 11:30:45 EST

To reproduce, import a log file using large log resource support and then browse the log in Log Viewer, you should see that the allElements (filtered) list in the Log view content provider is populated 3 times for each refresh/page up/page down operation.

Comment 3 Marius Slavescu

2007-01-22 13:00:48 EST

Just to give a sense of the impact of this defect, the time to refresh the page (when large log is used) could be around 20s so if you multiply that by 3 you get 1 minute of wait instead.

Page by page is much faster but you still don't want to wait 3 times more than the actual time spend to get the data from the database or in memory model.

The larger the in memory model is the longer the time to build the list of filter events is.

Comment 4 Eugene Chan

2007-01-31 18:13:22 EST

cannot be closed by i1

Comment 5 Steve Francisco

2007-05-08 13:14:05 EDT

Is there any progress on this problem?

Comment 6 Eugene Chan

2007-05-08 13:42:18 EDT

(In reply to comment #5)
> Is there any progress on this problem?
> 
Hi. No. Not yet. =(

Comment 7 Eugene Chan

2007-05-08 18:56:19 EDT

Created attachment 66380 [details]
patch

proposed patch.

org.eclipse.tptp.platform.log.views.internal.views.LogContentProvider.rebuildAllElements(Object) was called multiple time on view open/refresh/page up/page down events. It is a regression introduced in the changes of org.eclipse.tptp.platform.log.views.internal.views.LogContentProvider.prepareFiltersAndSortAttributes().

The patch adopts the change made in prepareFiltersAndSortAttributes and have rebuildAllElements() called once per listed event.

Comment 8 Eugene Chan

2007-05-09 11:05:17 EDT

Target i4, as it does not block i3 test pass.

Comment 9 Eugene Chan

2007-05-22 17:46:36 EDT

Approved by Project Lead and patch is submitted.

Comment 10 Paul Slauenwhite

2009-06-30 09:38:06 EDT

As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.