Strange problems from too many small objects...

JKnottJKnott Member ✭✭✭
edited August 2019 in Xamarin.Forms

Hello, all.
I have a LOT of small bits of data, I am storing and reading from a SQlite database. I think I am overloading the stack and then some, so I have some questions, I hope someone can please help me....

I am getting this output from the debugger around the time that my app freezes up.

        08-26 22:38:29.032 D/[email protected][PopupWindow:9c3a44e]( 9840): setView = android.widget.PopupWindow$PopupDecorView{9ce3255 V.E...... R.....I. 0,0-0,0} TM=true MM=false
    08-26 22:38:29.037 D/[email protected][PopupWindow:9c3a44e]( 9840): dispatchAttachedToWindow
    08-26 22:38:29.050 D/[email protected][PopupWindow:9c3a44e]( 9840): Relayout returned: old=[0,84][1440,2792] new=[0,84][1440,2792] result=0x7 surface={valid=true 507580899328} changed=true
    08-26 22:38:29.067 D/OpenGLRenderer( 9840): eglCreateWindowSurface = 0x762e3ff880, 0x762e2de010
    08-26 22:38:29.096 D/[email protected][PopupWindow:9c3a44e]( 9840): Relayout returned: old=[0,84][1440,2792] new=[0,84][1440,2792] result=0x1 surface={valid=true 507580899328} changed=false
    08-26 22:38:29.138 D/[email protected][PopupWindow:9c3a44e]( 9840): MSG_RESIZED: frame=Rect(0, 84 - 1440, 2792) ci=Rect(0, 0 - 0, 0) vi=Rect(0, 0 - 0, 0) or=1
    08-26 22:38:29.145 D/[email protected][PopupWindow:9c3a44e]( 9840): Relayout returned: old=[0,84][1440,2792] new=[0,84][1440,2792] result=0x1 surface={valid=true 507580899328} changed=false
    08-26 22:38:29.984 D/[email protected][PopupWindow:9c3a44e]( 9840): ViewPostIme pointer 0
    08-26 22:38:30.045 I/Raven.BoomStic( 9840): Explicit concurrent copying GC freed 61673(3MB) AllocSpace objects, 6(128KB) LOS objects, 58% free, 4MB/10MB, paused 53us total 27.985ms
    08-26 22:38:30.053 D/Mono    ( 9840): GC_TAR_BRIDGE bridges 2664 objects 5761 opaque 1644 colors 2662 colors-bridged 2643 colors-visible 2643 xref 222 cache-hit 0 cache-semihit 0 cache-miss 19 setup 0.18ms tarjan 2.14ms scc-setup 0.38ms gather-xref 0.05ms xref-setup 0.02ms cleanup 0.61ms
    08-26 22:38:30.053 D/Mono    ( 9840): GC_BRIDGE: Complete, was running for 44.95ms
    08-26 22:38:30.053 D/Mono    ( 9840): GC_MAJOR: (user request) time 21.39ms, stw 22.80ms los size: 1024K in use: 230K
    08-26 22:38:30.054 D/Mono    ( 9840): GC_MAJOR_SWEEP: major size: 7152K in use: 5435K
    08-26 22:38:30.350 D/[email protected][PopupWindow:9c3a44e]( 9840): ViewPostIme pointer 1
    08-26 22:38:31.062 D/[email protected][PopupWindow:9c3a44e]( 9840): ViewPostIme pointer 0
    08-26 22:38:31.112 I/Raven.BoomStic( 9840): Explicit concurrent copying GC freed 12078(488KB) AllocSpace objects, 0(0B) LOS objects, 59% free, 4MB/10MB, paused 46us total 22.531ms
    08-26 22:38:31.118 D/Mono    ( 9840): GC_TAR_BRIDGE bridges 1788 objects 2065 opaque 75 colors 1780 colors-bridged 1780 colors-visible 1780 xref 24 cache-hit 0 cache-semihit 0 cache-miss 0 setup 0.22ms tarjan 0.90ms scc-setup 0.27ms gather-xref 0.02ms xref-setup 0.01ms cleanup 0.28ms
    08-26 22:38:31.118 D/Mono    ( 9840): GC_BRIDGE: Complete, was running for 31.78ms
    08-26 22:38:31.118 D/Mono    ( 9840): GC_MAJOR: (user request) time 21.46ms, stw 23.09ms los size: 1024K in use: 349K
    08-26 22:38:31.118 D/Mono    ( 9840): GC_MAJOR_SWEEP: major size: 7280K in use: 5505K
    08-26 22:38:31.156 D/[email protected][PopupWindow:9c3a44e]( 9840): ViewPostIme pointer 1
    08-26 22:38:31.856 D/[email protected][PopupWindow:9c3a44e]( 9840): ViewPostIme pointer 0
    08-26 22:38:31.901 I/Raven.BoomStic( 9840): Explicit concurrent copying GC freed 4290(183KB) AllocSpace objects, 0(0B) LOS objects, 60% free, 3MB/9MB, paused 45us total 21.681ms
    08-26 22:38:31.906 D/Mono    ( 9840): GC_TAR_BRIDGE bridges 1466 objects 1728 opaque 73 colors 1461 colors-bridged 1461 colors-visible 1461 xref 17 cache-hit 0 cache-semihit 0 cache-miss 0 setup 0.13ms tarjan 0.55ms scc-setup 0.27ms gather-xref 0.02ms xref-setup 0.00ms cleanup 0.27ms
    08-26 22:38:31.906 D/Mono    ( 9840): GC_BRIDGE: Complete, was running for 29.47ms
    08-26 22:38:31.906 D/Mono    ( 9840): GC_MAJOR: (user request) time 19.00ms, stw 20.62ms los size: 1024K in use: 349K
    08-26 22:38:31.906 D/Mono    ( 9840): GC_MAJOR_SWEEP: major size: 7136K in use: 4992K

I can post the whole output if someone needs to see that as well...
This seems to happen most frequently, when I either use some regex searches on a string, or when I use a SyncFusion Picker that's been tweaked to get dates.

What I gather from this, is that I have far too much... stuff... on the stack...

Here are my questions...

1) Can I manually flush my app's stack? and free up lists and memory that are nolonger used?

2) Is there a way to load this data as a readonly onetime stack? In the past with C/C++ I had created an instance of some lists of data, that were independent of the apps main UI thread, I could then call back to bits of these pieces of memory when I needed them, and NOT have to create new lists every time the page/view/screen changed to another one within my app.

3) Can I create a FIFO stack to just force stuff out of memory when I decide (rather than wait for the garbage collector to get it for me)?

Mainly I would like to see about simply making my data static and only load it once at start up. I can then manage it and refresh it as needed. Basically creating a viewmodel, that runs in the App level space. I can see several benefits to this, but some potential headaches too. So before I run off and start redesigning how my app works completely, I'd like to get some feedback.

I can only assume that my assumption is correct, because every time a page loads it seems to need to recreate all the data it had all over again. Hence why I think creating a separate data layer would be best....

Am I barking up a wrong tree here? am I totally insane trying to manage my own memory space from C#?

I'm following the MVVM model as best as I can tell. But there is just a LOT, of data that's being passed around from screen to screen (view to view I suppose).

Ideally, I imagine that pages should be dumped once the screen/view is changed, but from what I can tell, the garbage collector leaves stuff there, and only removes it when the memory space is getting slim.

Can I request a larger stack to work with?

Anyhow, I have several questions there. Please forgive my rampant and nonlinear rambling, (I'm in a LOT of pain, and this is just adding confusion and befuddlement to the mix)

Any help would be most greatly appreciated!

Cheers!

Sign In or Register to comment.