- 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
- 2010-12-21: Madame Figaro brand new site by OSInet and others
- 2010-08-16: France.FR is back online with OSInet and Typhon
- 2010-06-15: the new France Culture, which OSInet helped reach its performance goals, is now online
Filling GtkTreeView ... fast
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
a sample built to demonstrate the performance gain obtained by
GtkListStore from the
GtkTreeView while filling the list with data, just
like one would wrap such fills in a
DisableControls pair in Delphi.
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).
|Rows||Fill while connected||Fill disconnected then reconnect|
|First pass||Next passes||First pass||Next passes|
Results compiled on a 2.8 GHz P4, 1 GB RAM, XP SP1.
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
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.