Inline below On Tue, Nov 15, 2016 at 12:43 PM, bilbosax <[email protected]> wrote:
> The big question is do Exceptions take up time? > Yes. > > I am finally able to get some good data into Scout to profile my mobile > application, and I am quite confused. The compiler finds no errors, > debugging throws no errors, my application is displaying all of the correct > data, but when I run Scout and look at a frame that is taking nearly > 4000ms, > I find that hundreds of exceptions are being thrown. They don't show that > they are taking any time in ms, but surely hundreds of them have to be > taking up some significant time. They are all TypeError Exceptions. I > assume that they mean that I assigning an incorrect value to a datatype of > some sort. Here is a picture of a grab of the error list: > > <http://apache-flex-users.2333346.n4.nabble.com/file/n14126/scout2.jpg> > > If I mouse over any of the exceptions, it gives me a ton of data that I > don't really understand. It does not give you a line-number of where the > exception is being thrown, so I don't know exactly what variable is being > cast wrong. If anybody could take a look at this and help me narrow down a > value that I am assigning incorrectly, I would greatly appreciate it. I am > assuming that it is an itemrenderer value that I use "data" to assign > values > to labels. Do you think that hundreds of these exceptions are taking any > appreciable amount of time? > > Exception: TypeError > MethodInfo-12677 > mx.binding::Binding/wrapFunctionCall > mx.binding::Binding/innerExecute > mx.binding::Binding/wrapFunctionCall > mx.binding::Binding/execute > mx.binding::BindingManager$/executeBindings > renderers::targetListRenderer/_targetListRenderer_Label3_i > renderers::targetListRenderer/_targetListRenderer_Group5_i > renderers::targetListRenderer/_targetListRenderer_HGroup2_c > renderers::targetListRenderer/_targetListRenderer_Group4_c > renderers::targetListRenderer/_targetListRenderer_HGroup1_c > renderers::targetListRenderer > mx.core::ClassFactory/newInstance > spark.components::DataGroup/createRenderer > spark.components::DataGroup/createVirtualRendererForItem > spark.components::DataGroup/getVirtualElementAt > spark.layouts::VerticalLayout/updateDisplayListVirtual > spark.layouts::VerticalLayout/updateDisplayList > spark.components.supportClasses::GroupBase/updateDisplayList > spark.components::DataGroup/updateDisplayList > mx.core::UIComponent/validateDisplayList > mx.managers::LayoutManager/validateDisplayList > mx.managers::LayoutManager/doPhasedInstantiation > mx.managers::LayoutManager/validateNow > mx.core::UIComponent/commitCurrentState > mx.core::UIComponent/setCurrentState > mx.core::UIComponent/set currentState > views::RealDealsTabletRealDealsMainView/compClickedHandler > flash.events::EventDispatcher/dispatchEvent > mx.core::UIComponent/dispatchEvent > views::RealDealsTabletRealDealsMainViewInnerClass0/myEventDispatcher > views::RealDealsTabletRealDealsMainViewInnerClass0/___ > RealDealsTabletRealDealsMainViewInnerClass0_Button1_click > > > It could be a null pointer 1009. The data property can be set to null especially when using binding. Here's a util to debug bindings. https://github.com/vectorscape/monet/blob/b0ea9d8eec7a8800853e49ac924bb171f72175d9/flex/src/com/velti/monet/utils/BindingDebugger.as You may want to avoid using mxml for itemRenderers and also avoid using bindings inside the item renderers all together. > > > -- > View this message in context: http://apache-flex-users. > 2333346.n4.nabble.com/Scout-What-does-this-mean-tp14126.html > Sent from the Apache Flex Users mailing list archive at Nabble.com. >
