title: Firebase Android: slow "join" using many listeners, seems to contradict documentation
body: <p>Implementing an Android+Firebase app, which has a many-to-many relationship: User &lt;-> Widget (Widgets can be shared to multiple users).</p>
  
  <p>Considerations:</p>
  
  <ol>
  <li>List all the Widgets that a User has.</li>
  <li>A User can only see the Widgets which are shared to him/her.</li>
  <li>Be able to see all Users to whom a given Widget is shared.</li>
  <li>A single Widget can be owned/administered by multiple Users with equal rights (modify Widget and change to whom it is shared). Similar to how Google Drive does sharing to specific users.</li>
  </ol>
  
  <p>One of the approaches to implement fetching (join-style), would be to go with this advice: <a href="https://www.firebase.com/docs/android/guide/structuring-data.html" rel="nofollow noreferrer">https://www.firebase.com/docs/android/guide/structuring-data.html</a> ("<code>Joining Flattened Data</code>"):</p>
  
  <pre><code>// fetch a list of Mary's groups
  ref.child("users/mchen/groups").addChildEventListener(new ChildEventListener() {
    @Override
    public void onChildAdded(DataSnapshot snapshot, String previousChildKey) {
      // for each group, fetch the name and print it
      String groupKey = snapshot.getKey();
      ref.child("groups/" + groupKey + "/name").addListenerForSingleValueEvent(new ValueEventListener() {
        @Override
        public void onDataChange(DataSnapshot snapshot) {
          System.out.println("Mary is a member of this group: " + snapshot.getValue());
        }
        @Override
        public void onCancelled(FirebaseError firebaseError) {
          // ignore
        }
      });
    }
  });
  </code></pre>
  
  <p>This prompts the question whether having potentially many listeners will have a negative impact on performance or perhaps would hit some hard limit.</p>
  
  <p>But we get reassured in the doc:</p>
  
  <blockquote>
    <p>Is it really okay to look up each record individually? Yes. The Firebase protocol uses web sockets, and the client libraries do a great deal of internal optimization of incoming and outgoing requests. Until we get into tens of thousands of records, this approach is perfectly reasonable. In fact, the time required to download the data (i.e. the byte count) eclipses any other concerns regarding connection overhead.</p>
  </blockquote>
  
  <p>But, to be sure, I've made a little test app which compares 2-approaches:</p>
  
  <ol>
  <li>Attaching many <code>ValueEventListener</code>-s to all widgets one-by-one (as per Firebase's "structuring-data" guide mentioned above)</li>
  <li>Attaching a single <code>ChildEventListener</code> to a node which hosts all the widgets (requires adequate structuring of User's Widgets under one node)</li>
  </ol>
  
  <p>Tested on 4 different devices and android versions (4.x - 5.x). Firebase lib: <code>'com.firebase:firebase-client-android:2.3.1'</code>. <br>
  In the first approach the performance was rather disappointing.
  I consistently saw ~15-100 events/s. The lowest performance, ~15 events/s was coming up quite often, so looks like it should be taken seriously.
  In such case, if the User had 100 Widgets, it would take ~6seconds to get info about all Widgets (e.g. scrolling a list). This is too slow.
  With 1000 Widgets, it often took as much as 40 seconds to fetch their info by separate listeners. Way too slow.
  <br><br>
  In the second approach I observed 200-3000 events/s. Thus 15-30 times faster than the first approach!<br>
  So looks like the reassurance in Firebase doc <code>[...] Until we get into tens of thousands of records, this approach is perfectly reasonable [...]</code> is not really accurate given how slowly it worked.
  <br></p>
  
  <p>Given all that, I have 4 inter-related questions.</p>
  
  <ol>
  <li>Can anyone confirm/disprove my findings given their own experience/benchmarks? Info regarding other platforms also welcome, as there is a plan to develop this app on multiple platforms.</li>
  <li>What could be the reason for such dramatic difference of performance? Internal data structures perhaps?</li>
  <li>Is there any way to improve the performance while still keeping the first (multi-listener) approach?</li>
  <li>Should the multi-listener approach be ditched completely in favor of a denormalized multi-copy approach which was presented in Firebase+Udacity tutorial (<a href="https://github.com/udacity/ShoppingListPlusPlus" rel="nofollow noreferrer">https://github.com/udacity/ShoppingListPlusPlus</a> in the "userLists" node - where they keep per-user copies of shopping list info) ? I ask about implications of this approach, in another question - <a href="https://stackoverflow.com/questions/36046721/firebase-structuring-data-via-per-user-copies-risk-of-data-corruption">Firebase: structuring data via per-user copies? Risk of data corruption?</a> .</li>
  </ol>
  
  <p>Any other hints/considerations welcome.
  TIA.</p>