Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Some more observations that might be helpful:</p> <p>I am able to reproduce the problem, using flow layout with around 175 items visible at once: it scrolls smoothly in the simulator but lags like hell on iPhone 5. Made sure they are opaque etc.</p> <p><img src="https://i.stack.imgur.com/Sq3a9.png" alt="enter image description here"></p> <p>What ends up taking the most time seems to be work with a mutable NSDictionary inside <code>_updateVisibleCellsNow</code>. Both copying the dictionary, but also looking up items by key. The keys seems to be UICollectionViewItemKey and the <code>[UICollectionViewItemKey isEqual:]</code> method is the most time consuming method of all. UICollectionViewItemKey contains at least <code>type</code>, <code>identifier</code> and <code>indexPath</code> properties, and the contained property indexPath comparison <code>[NSIndexPath isEqual:]</code> takes the most time.</p> <p>From that I'm guessing that the hash function of UICollectionViewItemKey might be lacking since <code>isEqual:</code> is called so often during dictionary lookup. Many of the items might be ending up with the same hash (or in the same hash bucket, not sure how NSDictionary works).</p> <p>For some reason it is faster with all items in 1 section, compared to many sections with 7 items in each. Probably because it spends so much time in NSIndexPath isEqual and that is faster if the row diffs first, or perhaps that UICollectionViewItemKey gets a better hash.</p> <p>Honestly it feels really weird that UICollectionView does that heavy dictionary work every scroll frame, as mentioned before each frame update needs to be &lt;16ms to avoid lag. I wonder if that many dictionary lookups either is:</p> <ul> <li>Really necessary for general UICollectionView operation</li> <li>There to support some edge case rarely used and could be turned off for most layouts</li> <li>Some unoptimized internal code that hasn't been fixed yet</li> <li>Some mistake from our side</li> </ul> <p>Hopefully we will see some improvement this summer during WWDC, or if someone else here can figure out how to fix it.</p>
    singulars
    1. This table or related slice is empty.
    1. POUICollectionView performance - _updateVisibleCellsNow
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USAndreas Karlsson
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COGreat observations. Perhaps this is something to file a radar on.
      singulars
      1. PO
      1. USOskar
    2. COWhen you think about it, a dictionary lookup is required because, unlike a table view, there is no guaranteed order to the display of the cells. You can define the cells to follow any rules at any time and the collection view needs to know for any given frame which cells are on screen and where they should be placed (even if cells are visible from sections 1, 2 and 3, there is still no guarantee all cells from section 2 are on screen). This becomes very clear when you roll your own layout. An array won't do because the required index paths will often be discontinuous.
      singulars
      1. PO
      1. USTheBasicMind
    3. COAndreas are you rolling your own Layout object? I too found NSDictionary performance issues but *i think* this was relieved somewhat when I started caching any generated layoutAttributes objects. I've noticed bad things happen if these are not cached so the exact same attributes object is returned for a given IndexPath when future requests for layout objects are made. I say *think* because unfortunately I didn't notice the improvement in that metric until some time later and haven't yet run specific tests to confirm.
      singulars
      1. PO
      1. USTheBasicMind
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload