Re: Rendering performance
Ok, that might have something to do with it! :-D Thanks! 2016-06-16 16:21 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > The models and data providers are asked for their data at render time. > Once the final data is available Wicket starts populating the HTML markup > with it. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Jun 16, 2016 at 4:17 PM, Lars Törner <lars.tor...@gmail.com> > wrote: > > > Hi Martin, > > > > we use wicket 6.22. > > > > Doesn't the rendering take place when everything else is done? I.e the > > wicket components are already created and populated with data when the > > rendering phase starts. I guess I have to dig a bit deeper... anyway, > > thanks for your quick answers! > > > > Lasse > > > > 2016-06-16 15:47 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > > > > > Also it could be similar to > > > https://issues.apache.org/jira/browse/WICKET-6177. > > > There the user also has a lot of components in the tree and this takes > > time > > > at page serialization time. > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov <mgrigo...@apache.org > > > > > wrote: > > > > > > > Hi Lasse, > > > > > > > > Which version of Wicket do you use ? > > > > > > > > I think you will have to use a profiler to see where the times is > > spent. > > > > It could be Wicket, but also it could be the application spending a > lot > > > of > > > > time while loading the data which should be rendered. > > > > > > > > > > > > Martin Grigorov > > > > Wicket Training and Consulting > > > > https://twitter.com/mtgrigorov > > > > > > > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner <lars.tor...@gmail.com> > > > > wrote: > > > > > > > >> Hi, > > > >> > > > >> we have an issue with rendering performance and I wonder if there > are > > > any > > > >> common misusages of wicket when it comes to this. > > > >> > > > >> When rendering a fully expanded tree with 160 top level nodes and > > mostly > > > >> no > > > >> subtrees (an expanded node is a forms with a bunch of labels and > > > >> attributes) it takes about 20 seconds for the page to load (actually > > > it's > > > >> an Ajax request) and it seems that most of this time is spent when > > > wicket > > > >> renders the components. > > > >> > > > >> For one ot these 160 nodes, which has some sub nodes and forms, > > > rendering > > > >> takes about half a second. > > > >> > > > >> I'm using the RenderPerformanceListener from wicket-devutils to do > the > > > >> measuring and gets, for the entire expanded tree, over 22 000 > > > >> "afterRender" > > > >> rows in the log from the RenderPerformanceListener. > > > >> This is in my opinion a huge number! > > > >> > > > >> - is it expected that rendering of so many components takes this > > amount > > > of > > > >> time? > > > >> - is this amount a sign of that we are using wicket in the wrong > way? > > > >> > > > >> > > > >> Don't know if this makes any sense to anyone but this is the last > > lines > > > of > > > >> the log output for one of the top level nodes: > > > >> > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > > > >> for 0ms > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > > > >> for 0ms > > > >> > > > >> > > &
Re: Rendering performance
The models and data providers are asked for their data at render time. Once the final data is available Wicket starts populating the HTML markup with it. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Jun 16, 2016 at 4:17 PM, Lars Törner <lars.tor...@gmail.com> wrote: > Hi Martin, > > we use wicket 6.22. > > Doesn't the rendering take place when everything else is done? I.e the > wicket components are already created and populated with data when the > rendering phase starts. I guess I have to dig a bit deeper... anyway, > thanks for your quick answers! > > Lasse > > 2016-06-16 15:47 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > > > Also it could be similar to > > https://issues.apache.org/jira/browse/WICKET-6177. > > There the user also has a lot of components in the tree and this takes > time > > at page serialization time. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov <mgrigo...@apache.org> > > wrote: > > > > > Hi Lasse, > > > > > > Which version of Wicket do you use ? > > > > > > I think you will have to use a profiler to see where the times is > spent. > > > It could be Wicket, but also it could be the application spending a lot > > of > > > time while loading the data which should be rendered. > > > > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner <lars.tor...@gmail.com> > > > wrote: > > > > > >> Hi, > > >> > > >> we have an issue with rendering performance and I wonder if there are > > any > > >> common misusages of wicket when it comes to this. > > >> > > >> When rendering a fully expanded tree with 160 top level nodes and > mostly > > >> no > > >> subtrees (an expanded node is a forms with a bunch of labels and > > >> attributes) it takes about 20 seconds for the page to load (actually > > it's > > >> an Ajax request) and it seems that most of this time is spent when > > wicket > > >> renders the components. > > >> > > >> For one ot these 160 nodes, which has some sub nodes and forms, > > rendering > > >> takes about half a second. > > >> > > >> I'm using the RenderPerformanceListener from wicket-devutils to do the > > >> measuring and gets, for the entire expanded tree, over 22 000 > > >> "afterRender" > > >> rows in the log from the RenderPerformanceListener. > > >> This is in my opinion a huge number! > > >> > > >> - is it expected that rendering of so many components takes this > amount > > of > > >> time? > > >> - is this amount a sign of that we are using wicket in the wrong way? > > >> > > >> > > >> Don't know if this makes any sense to anyone but this is the last > lines > > of > > >> the log output for one of the top level nodes: > > >> > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > > >> for 0ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > > >> for 0ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' > > >> for 0ms > > >> > > >> > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell
Re: Rendering performance
Hi Martin, we use wicket 6.22. Doesn't the rendering take place when everything else is done? I.e the wicket components are already created and populated with data when the rendering phase starts. I guess I have to dig a bit deeper... anyway, thanks for your quick answers! Lasse 2016-06-16 15:47 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > Also it could be similar to > https://issues.apache.org/jira/browse/WICKET-6177. > There the user also has a lot of components in the tree and this takes time > at page serialization time. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > Hi Lasse, > > > > Which version of Wicket do you use ? > > > > I think you will have to use a profiler to see where the times is spent. > > It could be Wicket, but also it could be the application spending a lot > of > > time while loading the data which should be rendered. > > > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner <lars.tor...@gmail.com> > > wrote: > > > >> Hi, > >> > >> we have an issue with rendering performance and I wonder if there are > any > >> common misusages of wicket when it comes to this. > >> > >> When rendering a fully expanded tree with 160 top level nodes and mostly > >> no > >> subtrees (an expanded node is a forms with a bunch of labels and > >> attributes) it takes about 20 seconds for the page to load (actually > it's > >> an Ajax request) and it seems that most of this time is spent when > wicket > >> renders the components. > >> > >> For one ot these 160 nodes, which has some sub nodes and forms, > rendering > >> takes about half a second. > >> > >> I'm using the RenderPerformanceListener from wicket-devutils to do the > >> measuring and gets, for the entire expanded tree, over 22 000 > >> "afterRender" > >> rows in the log from the RenderPerformanceListener. > >> This is in my opinion a huge number! > >> > >> - is it expected that rendering of so many components takes this amount > of > >> time? > >> - is this amount a sign of that we are using wicket in the wrong way? > >> > >> > >> Don't know if this makes any sense to anyone but this is the last lines > of > >> the log output for one of the top level nodes: > >> > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' > >> for 1ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' > >> for 2ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' > >> for 2ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeR
Re: Rendering performance
Also it could be similar to https://issues.apache.org/jira/browse/WICKET-6177. There the user also has a lot of components in the tree and this takes time at page serialization time. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi Lasse, > > Which version of Wicket do you use ? > > I think you will have to use a profiler to see where the times is spent. > It could be Wicket, but also it could be the application spending a lot of > time while loading the data which should be rendered. > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner <lars.tor...@gmail.com> > wrote: > >> Hi, >> >> we have an issue with rendering performance and I wonder if there are any >> common misusages of wicket when it comes to this. >> >> When rendering a fully expanded tree with 160 top level nodes and mostly >> no >> subtrees (an expanded node is a forms with a bunch of labels and >> attributes) it takes about 20 seconds for the page to load (actually it's >> an Ajax request) and it seems that most of this time is spent when wicket >> renders the components. >> >> For one ot these 160 nodes, which has some sub nodes and forms, rendering >> takes about half a second. >> >> I'm using the RenderPerformanceListener from wicket-devutils to do the >> measuring and gets, for the entire expanded tree, over 22 000 >> "afterRender" >> rows in the log from the RenderPerformanceListener. >> This is in my opinion a huge number! >> >> - is it expected that rendering of so many components takes this amount of >> time? >> - is this amount a sign of that we are using wicket in the wrong way? >> >> >> Don't know if this makes any sense to anyone but this is the last lines of >> the log output for one of the top level nodes: >> >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' >> for 0ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' >> for 0ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' >> for 0ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' >> for 1ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' >> for 2ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' >> for 2ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' >> for 26ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow' >> for 27ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent' >> for 27ms >> >> >> 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:bra
Re: Rendering performance
Hi Lasse, Which version of Wicket do you use ? I think you will have to use a profiler to see where the times is spent. It could be Wicket, but also it could be the application spending a lot of time while loading the data which should be rendered. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner <lars.tor...@gmail.com> wrote: > Hi, > > we have an issue with rendering performance and I wonder if there are any > common misusages of wicket when it comes to this. > > When rendering a fully expanded tree with 160 top level nodes and mostly no > subtrees (an expanded node is a forms with a bunch of labels and > attributes) it takes about 20 seconds for the page to load (actually it's > an Ajax request) and it seems that most of this time is spent when wicket > renders the components. > > For one ot these 160 nodes, which has some sub nodes and forms, rendering > takes about half a second. > > I'm using the RenderPerformanceListener from wicket-devutils to do the > measuring and gets, for the entire expanded tree, over 22 000 "afterRender" > rows in the log from the RenderPerformanceListener. > This is in my opinion a huge number! > > - is it expected that rendering of so many components takes this amount of > time? > - is this amount a sign of that we are using wicket in the wrong way? > > > Don't know if this makes any sense to anyone but this is the last lines of > the log output for one of the top level nodes: > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > for 0ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > for 0ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' > for 0ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' > for 1ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' > for 2ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' > for 2ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' > for 26ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow' > for 27ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent' > for 27ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1' > for 27ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection' > for 28ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm' > for 29ms > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component' > for 29ms > > > 'mainContent:detailViewer:detailAndSidebarConta
Rendering performance
Hi, we have an issue with rendering performance and I wonder if there are any common misusages of wicket when it comes to this. When rendering a fully expanded tree with 160 top level nodes and mostly no subtrees (an expanded node is a forms with a bunch of labels and attributes) it takes about 20 seconds for the page to load (actually it's an Ajax request) and it seems that most of this time is spent when wicket renders the components. For one ot these 160 nodes, which has some sub nodes and forms, rendering takes about half a second. I'm using the RenderPerformanceListener from wicket-devutils to do the measuring and gets, for the entire expanded tree, over 22 000 "afterRender" rows in the log from the RenderPerformanceListener. This is in my opinion a huge number! - is it expected that rendering of so many components takes this amount of time? - is this amount a sign of that we are using wicket in the wrong way? Don't know if this makes any sense to anyone but this is the last lines of the log output for one of the top level nodes: 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' for 1ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' for 2ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' for 2ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' for 26ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection' for 28ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm' for 29ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component' for 29ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content' for 36ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node' for 36ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:subtree:branches' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:subtree' for 1ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8' for 37ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches'
