Latest sites

  • 2017-11-26: New Drupal 8 site at Rue du Commerce, architected and tech-led by OSInet, just went throught Black Friday week with flying colors thanks to RabbitMQ
  • 2017-05-26: New headless Drupal 8 / Symfony 3 site at FranceTV Sport, architected and tech-led by OSInet, with RabbitMQ
  • 2017-02-20: New Drupal 8 site galaxy (+/- 70 sites) for Agences Régionales de Santé architected and tech-led by OSInet, delivered by Klee
  • 2015-08-21: 50% less server load with MongoDB on the Drupal 7 site factory at France Télévisions
  • 2015-07-15: Our first Drupal 8 production site at France Télévisions is live
  • 2014-08-18: 400% speedup in 3 weeks for http://france3-regions.francetvinfo.fr/ : who said Drupal back-offices had to be slow ?
  • 2014-02-07: Sotchi Olympics traffic not a problem for http://www.francetvsport.fr/ , which I rearchitected on Drupal 7 in 2013
  • 2011-09-14: Completed migration of FranceInfo.FR from SPIP to Drupal
  • 2011-07-13: The new social network features of Le Figaro are now powered by an OSInet-designed MongoDB implementation

Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

Filling GtkTreeView ... fast

GtkListStore performance A discussion these days on the PHP-GTK general mailing list revolved around the issue of feeding a large amount of rows to the model bound to a GtkTreeView.

Marc Quinton pasted a sample built to demonstrate the performance gain obtained by disconnecting the GtkListStore from the GtkTreeView while filling the list with data, just like one would wrap such fills in a EnableControls / DisableControls pair in Delphi.

Hard numbers

Surprisingly enough, he had to conclude the difference was not very significant, which seems rather counter-intuitive, so I thought I'd dig a bit deeper, and here are the data. The graph representing them is the one at the top of this post (click for larger graph).

Numbers are expressed in rows per millisecond
Rows Fill while connected Fill disconnected then reconnect
First pass Next passes First pass Next passes
2000 21,5 13,3 27,0 23,0
5000 20,0 12,5 26,3 21,7
10000 20,0 12.5 25,6 21,7
20000 20,0 12,5 25,6 21,7
50000 20,0 12,5 26,3 21,7
100000 20,0 11,2 24,4 21,3
500000 19,2 10,2 25,0 20,0

Results compiled on a 2.8 GHz P4, 1 GB RAM, XP SP1.

Side notes

Whatever option is chosen, the first pass of filling the list is always the fastest, presumably because it does not involve freeing the previous list first.

When choosing the "always connected" option, once the delay spent filling the list has been expanded, there still remains a delay for the GtkTreeView itself to catch up visually. With the larger lists, this becomes costly too: with the 500k rows list taking 26 (first pass) or 49 (next passes) seconds to fill, the view still requires 29 more seconds to redisplay.

On the other hand, when filling the list in disconnected mode and reconnecting once the list is filled, the view answers fluidly, with no perceptible delay, giving this option a much higher edge over the simpler solution of staying connected than the raw numbers might suggest.

It looks like this technique should go into a "PHP-GTK Best practices" somewhere.

Now, for some real speed...

This will only be of interest to C coders on the edge of GTK development, it seems, but numbers are in an entirely different class: 3 millions rows in 4 seconds.

This turns out as 750 rows/ms, instead of the 10 to 30 rows/ms we've been discussing.