最近だとこんな記事がありましたね｡

Atomの重要なﾌﾟﾘﾐﾃｨﾌﾞの最適化 | ｺﾝﾋﾟｭｰﾀｻｲｴﾝｽ | POSTD
http://postd.cc/optimizing-an-important-atom-primitive/

Atomというｴﾃﾞｨﾀで､ﾃｷｽﾄ内部の範囲を表現する｢ﾏｰｶ｣という構造体の扱いによって処理速度が大きく変わってくるという内容です｡

単にﾃｷｽﾄ内部の位置を保持するだけのﾏｰｶの処理でも､数が多くなると計算量が問題になってくるわけです｡
最近流行りのいわゆるﾋﾞｯｸﾞﾃﾞｰﾀやﾃﾞｨｰﾌﾟﾗｰﾆﾝｸﾞなども大概ﾃﾞｰﾀ量が多いので､常に計算量を意識しないと､まずまともに動きません｡
なので計算量のｵｰﾀﾞｰの話が古い､なんてことはありませんよ｡

さて上記のﾏｰｶの問題に戻りますが､｢効率的な探索方法｣のところで､探索木の中で22番目の位置を含む領域にｱｸｾｽするのがO(log(n))とされています｡同じように22番めの要素にｱｸｾｽする場合でも､配列に格納して22番目に直接ｱｸｾｽできればO(1)､配列ではなく隣接ﾘｽﾄでﾃﾞｰﾀを持っていて最初から一つずつたどる必要があればO(n)になります｡
他にも例えば｢全てのﾏｰｶの対を考え､そのﾏｰｶに重複する部分があれば出力しろ｣といった問題をﾅｲｰﾌﾞに処理するとO(n^2)になるでしょう｡

上記の話は｢一つの問題｣ではないので､お望みの回答ではないかもしれません｡
ただ個人的には､何に使うのかわからない呪術的なｱﾙｺﾞﾘｽﾞﾑを幾つか読み解くよりも､普段自分が書いている簡単なﾌﾟﾛｸﾞﾗﾑの計算量を確認したり､ﾃﾞｰﾀを1億倍にした場合の悪夢を体験させたりした方が良い学びになるかと思います｡

計算量を｢特殊なｱﾙｺﾞﾘｽﾞﾑを利用する際に優劣を決めるためのもの｣と考えるとつまらないですが､｢ﾌﾟﾛｸﾞﾗﾑが遅くて困ったときに見直すと､100倍以上の改善の可能性があるもの｣と考えると面白いですよ｡