Oracle Visual Builder: Applications That Outlive Their First Release · Module 15 · Performance
What breaks: three performance failures
Lesson 154 of 176 · 3 min
A PAGE ISSUING A CALL PER ROW, A LIST THAT WORKED ON TWENTY RECORDS, and A CACHED VALUE NOBODY INVALIDATED. THE CALL PER ROW IS THE ONE THAT DEGRADES WITH SUCCESS. It is imperceptible on the developer's five rows, noticeable at fifty, and unusable at five hundred — so it gets worse exactly as the application is adopted. Lesson 3, and it is invisible in the designer because nothing in the page says how many times its row content will run. THE LIST THAT WORKED ON TWENTY RECORDS IS THE SAME SHAPE FROM THE OTHER DIRECTION. No filter, no page size, everything fetched and everything rendered — correct on test data and unusable on real data. Lessons 2 and 4, and it is reported as "the application got slow" rather than as a defect, because nothing changed except the number of rows. AND THE CACHED VALUE NOBODY INVALIDATED IS THE…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Visual Builder: Applications That Outlive Their First Release, with a certificate on completion and a fourteen-day refund window.
In this module: Module 15 · Performance
- 1Measure before you change anything
- 2Over-fetching: the usual cause
- 3Too many calls
- 4Rendering a large list
- 5What to load, and when
- 6Caching, and when it lies
- 7What breaks: three performance failures
- 8Lab briefing · Ten times the data