買い物、自重。なバイク乗りの日記

1.5 sec. の壁をようやく突破。
といっても 1.47 sec. だが。(藁

今までは COUNT(フィールド名) のデータ保持の仕方がわからず SQL をカテゴリの数だけループさせていたのだが、今日、そのデータ保持の仕方がわかったので 1発取得のコードに変更してみた。
結果、1.55 sec. → 1.47 sec. とびみょーに早くなった。

サンプル：

#!/usr/local/bin/perl5.8.6
use DBI;
my $query_strings = "SELECT category_en,COUNT(category_en) FROM diary GROUP BY category_en";
$mysql_db = DBI->connect("DBI:mysql:DBNAME:localhost", USERNAME, PASSWORD);
$mysql_sth = $mysql_db->prepare("$query_strings");
my $ret = $mysql_sth->execute;
my @MAIN_CAT_DATA;
while (my $TMP_HASH = $mysql_sth->fetchrow_hashref) {
     printf("%-15s %5d\n", $TMP_HASH->{'category_en'}, $TMP_HASH->{'COUNT(category_en)'});
     push(@MAIN_CAT_DATA, "$TMP_HASH->{'category_en'}:$TMP_HASH->{'COUNT(category_en)'}");
}
$mysql_sth->finish;
$mysql_db->disconnect;

ただ単に $TMP_HASH->{'COUNT(category_en)'} とすればいいだけだったなんて・・・。
この部分は SELECT の後ろで指定するフィールド名がそのまま使われるようで、例えば "count(category_en)" と小文字にしたら、ブレス括弧内の文字列も "count(category_en)" と小文字にしなければならない。

だが、常時 1.50 sec. の壁を破っているわけではないのでまだ不満。
そこでどの部分が一番時間を食っているかを調べてみた結果、

0.167482 sec.
　　SELECT category_en,subcategory_en,COUNT(category_en)
　　　　FROM diary GROUP BY category_en,subcategory_en
0.164456 sec.
　　SELECT category_en,COUNT(category_en)
　　　　FROM diary GROUP BY category_en
0.145685 sec.
　　SELECT * FROM diary

"SELECT * FROM diary" より遅くなるのは GROUP BY と COUNT で集計してるからか・・・。＿|￣|○
とりあえずこれ以上はどうがんばっても早くなる可能性は無い模様。

今回はパスを使いまくったこともあって、いつもより比較的早く線画引けた。
色塗りは前回の "ぱんつはいてない" と噂されているアレを塗りおえてから・・・。

山銀さんとこの namelist.txt の調子不良が治ってよかったというか。
これらの出来事を見て思った。

次からはなりふりかまわず EUC で行く。

普通なら華麗にスルー出来るところが SJIS のおかげさまでバグを誘引するようなコードを書かなければならないこの苦労。
そんな苦労が嫌だったのでさくら for MySQL は全て EUC で記述。
すると、なんと楽にコーディングできるのでしょう。
おかげさまで気を遣わずにコーディングできるすばらしさ。

まぁこのあたりは「最初もしくは最終段階で文字コードを変換」という方法で切り抜けられるわけですが、やはり文字コードを統一した方が楽っちゃー楽。

ただ、最近は EUC を扱えるエディタも出てきているのでこの辺りは問題ないかと思ってますが。