Memory issue with slide-box and scrollable content

ionic-v1
#1

Hello,
still new to Ionic but trying to create a simple book application.

I’ve built it around the slide-box, having an ion-scroll inside each page. Content is being fed into the slides from a javascript array.

The book is approximately 200KB in size, so what I don;t understand is how the app ends up using between 200 and 600 MB in the iOS simulator. On the physical iPad I get a couple of memory warnings, and then it simply crashes.

This is the the source code of the template:

<ion-slide-box 
  does-continue='false' 
  show-pager='false' 
  auto-play='false' 
  delegate-handle="chapterslidebox" 
  direction="horizontal"
> 

  <ion-slide ng-repeat="chapter in book">
    <ion-scroll 
      class="padding hhappsSerif marginReading" 
      direction="y" 
      style="background-color: white; height:{{viewHeight-30}}px; width:{{viewWidth}}px; border:solid #880000 2px" 
      scroll="true" 
    >
      <div ng-bind-html="chapterBody($index)" style="height:100%;width:100%; background:white"></div>
    </ion-scroll>
  </ion-slide>
</ion-slide-box>

Any suggestions?

How would you typically track down a memory leak in a javascript app?

Thanks for any advice :blush:

#2

For typically tracking down memory leaks, refer to https://speakerdeck.com/addyosmani/javascript-memory-management-masterclass for example, has some nice resources.

I assume this is a problem with the amount of html in your app. Basically mobile principle’s are as follows: hybrid apps are great at large javascript memory’s, and suck at having large amounts of html. Therefore, we must always try to keep the amount of html in a page as low as possible. With the slide-box, all slides are prerendered if I recall correctly. The collection-repeat on the other hand, is a mobile optimized (espescially for large amounts of data) version of the normal list. To get the same situation here, you would need to have a collection-slide-box principle, which is not (yet?) implemented in ionic.

Basically, with only one bookpage, your app will be low on memory (please check), and with 100 pages, the app will be higher in memory. I don’t think there will be a memory leak (as in, memory keeps growing without adding data), for if you exit the book-page I assume it will be removed… Not tested though… Just putting up a theory here, which is a typical situation which I’ve seen many times.

#3

Yes, if I reduce the number of pages, the memory consumption will be reduced. But it’s still setting a very large memory footprint comparing with the amount of text. (More than 100 MB for 43 KB of text).

Also true that if I move away from the slide-box, a big chunk of the memory will be released: It went from 108 MB to around 65 MB which is still insane.

I’ve also tried using the collection-repeat, but could not make it work with the slide-box.

I’ve even tried to implement a sort of lazy-loading system where only a few pages would exist in the slide-box at the time. But since it needs to perform a refresh (which is visible and not pretty) with every content update, this is not an option.

I appreciate the pointers you’ve given. Unfortunately, in this case, it means that I cannot use Ionic for this product.

Thanks

#4

I have no clue why the memory consumption without the slidebox is so high! Might be that angular performs some magic on the scope variables, which makes it really bad with larger batches of text (43KB of text is not that much though…)

Are you performing anything on it that would make things more complicated?

I would like for @mhartington to reveal any ionic features that combines the collection repeat principle on the slide boxes, but I doubt it is already implemented? If it isn’t, ionic might not be the best fit for you right now indeed.

How often will the content update? I don’t know why a content update would be visible… There must be ways to prevent this, after all, a book will not typically change it’s content while you are reading it (and if it is, it probably isn’t important to refresh the content untill you open it again, therefore, syncing whilst reading might not be viable?)

#5

The content of the book is never supposed to be updated, once it’s assigned to the slide-box. (It has a randomize feature that allows the chapters to be ordered randomly, but I’ve taken that out now, while I’m testing).

The reason why I needed to refresh the slide-box was to support the lazy-loading mechanism I made. It kept the size of the book down to just three pages: The “current”, the “previous” and the “next” page. On every page change, the pages would then be updated with the correct content.

As I recall it, the only way I could keep the pages scrollable was if I forced a refresh using the “update()” method on the slide-box delegate, and this is the one that was visible to the user (it would draw three rectangles on screen and then move them into correct positioning some milliseconds later).

#6

Hmm I hope you can wait till @mhartington responds, (and at the same time, I hope for you he does fast ;)), because it sounds like the slide-box must have a way to update without this being visible… No experience with slide-box on this subject though at my end though.

Seems like you’ve tried everything you could so far though :slight_smile: Maybe reproduce a codepen to show the visual update, because it sounds like an issue that isn’t desired in any situation, might be just a bug in ion-slide-box

#7

Hey guys, a bit late to the conversation.

So the slide-box updates are in the work, as well have an open PR for it

When this stuff is finished, slide-box will kick ass, and be a lot more performant. The current implementation of slide-box is a bit rough so once this one is finished, it will be a big boost and should take care of a lot of performance issues

2 Likes
#8

Hi @mhartington, is there an expected release date (even in the nightly build)? I’m planning to launch an iOS app using slide-boxes very soon, so wondering if it’s worth waiting a few days.

Thanks

#9

@henrik242 sound like the WIP @mhartington posted is exactly what is causing your problem (at least the current next and previous is scheduled in the WIP, including some perfromance issues). Might be worth the wait in my opinion… Not sure about deadlines etc on your side though :wink:

@mhartington any ideas on expected release like @pierre asked? Sounds like an awesome release to me :slight_smile: And I’m planning to use slide box in my project as well.

#10

I can let you both know if a few hours, meeting time with everyone

2 Likes
New version of slidebox
#11

@mhartington great, looking forward!

1 Like
#12

Hi @mhartington, how did the meeting go?

#13

This is really exciting news! Looking much forward to testing this :slight_smile:

#14

I tried to implement exactly the same lazy-loading mecanism and faced the same issue…
Knowing that the Ionic team is working on a better slide-box, I decided to postpone my work on this…

About the memory issues, I’m curious to know if you tried to check the memory consumption in chrome (desktop) to see if it is really less…

#15

Hi @elSolo,
I loaded the app in Google Chrome, but I’m not entirely sure about the exact memory consumption of the specific app. Google spawns a number of helpers, each taking up some memory, and the Google Chrome process itself eats up around 50 MB upon launch.

Browsing to the app increases the memory consumption of the main Chrome process as well as one or two of the helper processes. Tried to do this a couple of times, but could not really determine anything from it.

Safari spawns a Safari process as well as a Safari Web content process. They take up approx 35 MB in total. When browsing to the app, the sum is increased to around 70 MB.

#16

This problem causes my navigation to be quite laggy. Looking forward to the update! :slight_smile:

#17

Hey everyone, so the meeting went well. A lot of the work for the new slide-box implementation is done, it’s just the last few part that need to finished up. Expect this and a few other things to make their way into the framework before 1.0 final :wink:

1 Like
#18

That’s great news!

Is the new slide-box likely to be part of the next beta?

How far (in terms of approximate number of weeks) are you from a final version?

/h

#19

Can put a date on when 1.0 will be out. If something happens and we can’t make it, we don’t want to seem like liars :smile:

What I can say is that we’re working to get the beta’s finalized soon and start doing a few RC.

#20

How far (in terms of approximate number of weeks) are we from the next beta release(with the new slide-box update)? :smiley: