カテゴリー別アーカイブ: Uncategorized

[C#] 開発メモ クラス検索のパフォーマンスについて

現在開発中のC#のプロジェクトで静的フィールドのメモリ内に
リストを持ち、必要に応じてメモリのリストよりクラスを検索して
返しているロジックがあります。

この検索ロジックですが、List<T>で持っており、LINQのwhere句で
検索を行っています。

もし遅いようであれば、リストをSortedListを使うなり、ListのBinarySearch
を利用することで対応しようと思っていたのですが、せっかくなので
多めのテストデータを使ってパフォーマンステストを実施してみました。

ここでデータは予めソートされていることを前提とします。

先に比較結果を記述します。

[リストへ100,000件追加]
List型(1回目):0.234秒
List型(2回目):0.234秒
List型(3回目):0.218秒
SortedList型(1回目):1.093秒
SortedList型(2回目):1.125秒
SortedList型(3回目):1.171秒

[100,000件から1件のレコードを1,000回検索]
List型(LINQのwhere句)(1回目):51.312秒
List型(LINQのwhere句)(2回目):51.171秒
List型(LINQのwhere句)(3回目):51.093秒
List型(BinarySearch)(1回目):0.015秒
List型(BinarySearch)(2回目):0.015秒
List型(BinarySearch)(3回目):0.015秒
SortedList型(1回目):0.015秒
SortedList型(2回目):0.015秒
SortedList型(3回目):0.015秒

この結果を見る限り、利用するならリストへの追加、検索の
ともに速いList型のBinarySearchがよさそうです。

ただ、ここでは1レコードを取得するテストを行いましたが
実際のプロジェクトでは範囲検索でリストを取得する処理も
行っているので、若干工夫が必要になりそうです。

ちなみにSortedList型でLINQを使って同じように検索すると
53.062秒と遅くなりました。LINQを使う場合はSortedListにしても
変わりはないようです・・・

参考までにテストの際に使用したソースを以下に記述します。

[検索するクラス]
public class Table
{
public String Key1 { get; set; }
public String Key2 { get; set; }
public String Key3 { get; set; }
public String Key4 { get; set; }
public String Key5 { get; set; }
public String Value { get; set; }
}

[比較用クラス]
public class TableCompare : IComparer<Table>
{
public int Compare(Table x, Table y)
{
if (x.Key1 != y.Key1)
{
return String.Compare(x.Key1, y.Key1);
}
if (x.Key2 != y.Key2)
{
return String.Compare(x.Key2, y.Key2);
}
if (x.Key3 != y.Key3)
{
return String.Compare(x.Key3, y.Key3);
}
if (x.Key4 != y.Key4)
{
return String.Compare(x.Key4, y.Key4);
}
return String.Compare(x.Key5, y.Key5);
}
}

リストへの追加処理

[List型]
List<Table> lstTable = new List<Table>();
for (Int32 i = 0; i < 100000; i++)
{
Table table = new Table();
table.Key1 = “1”;
table.Key2 = “2”;
table.Key3 = “3”;
table.Key4 = “4”;
table.Key5 = String.Format(“{0:00000}”, i);
table.Value = i.ToString();
lstTable.Add(table);
}

[SortedList型]
SortedList<Table, Table> slstTable = new SortedList<Table, Table>(new TableCompare());
for (Int32 i = 0; i < 100000; i++)
{
Table table = new Table();
table.Key1 = “1”;
table.Key2 = “2”;
table.Key3 = “3”;
table.Key4 = “4”;
table.Key5 = String.Format(“{0:00000}”, i);
table.Value = i.ToString();
slstTable.Add(table, table);
}

検索の比較

[List型(LINQのwhere句)]
for (Int32 i = 0; i < 1000; i++)
{
Random rm = new Random(i);
Int32 key = rm.Next(100000);

Table table = lstTable.Where(m =>
m.Key1 == “1”
&& m.Key2 == “2”
&& m.Key3 == “3”
&& m.Key4 == “4”
&& m.Key5 == String.Format(“{0:00000}”, key))
.FirstOrDefault();
}

[List型(BinarySearch)]
for (Int32 i = 0; i < 1000; i++)
{
Random rm = new Random(i);
Int32 key = rm.Next(100000);

Table tableKey = new Table();
tableKey.Key1 = “1”;
tableKey.Key2 = “2”;
tableKey.Key3 = “3”;
tableKey.Key4 = “4”;
tableKey.Key5 = String.Format(“{0:00000}”, key);

Int32 index = lstTable.BinarySearch(tableKey, new TableCompare());
Table table = lstTable[index];
}

[SortedList型]
for (Int32 i = 0; i < 1000; i++)
{
Random rm = new Random(i);
Int32 key = rm.Next(100000);

Table tableKey = new Table();
tableKey.Key1 = “1”;
tableKey.Key2 = “2”;
tableKey.Key3 = “3”;
tableKey.Key4 = “4”;
tableKey.Key5 = String.Format(“{0:00000}”, key);

Table table = slstTable[tableKey];
}

VRゴーグル「GearVR」を触ってみた

Oculus Rift を筆頭にVR(仮想現実)コンテンツ用のデバイスが一般的になりつつある。

そのデバイスのひとつである「Gear VR(Androidスマホがそのままゴーグルとして使えるデバイス)」の体験コーナーが

福岡のヨドバシカメラに設置されていたので実際に触ってみた。

image

Oulus Riftと比べて、まずは良い点。

  •  軽い
    • かなり軽い。首を大きく動かすコンテンツもあるので軽いほうが疲れにくい。
  • ケーブルレス
    • Oculusの接続ごちゃごちゃに比べてとってもスマート。首を動かすときの邪魔にもならない。
  • 画質が良い(ように感じた)
    • Oculus Riftの時に感じた、画面のドット感のようなものが気にならなかった。
  • 単体で動作可能
    • Oculus Riftのように別途PCの用意がいらない。完全に単独で動作させることが可能。

続いて、悪い点。

  • 稼働時間
    • 単体で動作する反面、バッテリーに依存することになる。
      充電しながら動作させることも出来るのかもしれないが、せっかくのケーブルレスのメリットが犠牲になる。
  • 性能の限界
    • 本体となるAndroid端末の性能に依存する。用意されていたデモ用コンテンツ程度であれば動作に問題がないが、より作りこんだコンテンツを用意する際は注意が必要。
  •  メガネをかけた人には向かないのかもしれない。
    • これはOculus Riftの時にも感じたことだが、メガネをかけている人はそのままメガネの上から装着することになり、メガネの形状によってはうまく体験できない。

やはり後発だけあって、Oculus Riftより優れている点が多く感じた。

問題は端末単体で購入が難しく、回線契約が必須となる点である。

 

開発者としては選択肢が増えることは嬉しい事なので、

メリット・デメリットをケースに合わせて使い分けたい。

車載アプリについて

以前車関係のお仕事をさせてもらったことがあり、
気になる記事を見つけたのでお知らせします。
トヨタとフォードがスマートデバイスリンク(SDL)を使用した車載システムを今後、
トヨタ・レクサス車両に導入するための検討に入ることで合意を発表したというものです。

まず、SDLとはスマホアプリを車載システム上で利用するための
オープンソースプラットフォームとなります。

これにより車内で音声やタッチパネルにて、スマホアプリを使用したり
道路情報などを利用することができるようになります。
また、アプリ開発に携わる人にとっては複数の車載システム上で扱えるアプリを
一度で開発できるため短期間で多くのユーザーに提供することができるようになります。

車載用アプリとして、
・ドコモ ドライブネット
・グーグル Android Auto
などがあります。

私自身車載用スマホアプリというものがあるのをこの記事を見て、
はじめて知りました。
また、今後車内でスマホを操作せずタッチパネルなどで、
メールや今後の予定などを音声で読み上げてもらったり、
音楽などの使い慣れたアプリを使用できるようになるのは、
運転中など、より一層快適なものになると思いました。

参照URL
・excite.ニュース トヨタ、フォードの「スマートデバイスリンク」をレクサスに導入か
http://www.excite.co.jp/News/column_g/20150603/Cobs_205822.html
・グーグル Android Auto
http://appllio.com/20150320-6289-android-auto-app
・ドコモ ドライブネット
http://pioneer.jp/carrozzeria/splink/appli_unit/sph-da09-2_sph-da05-2/docomo_position.html

 

PS メモ

こんにちは
まえだです。

たまにPSを使うことがありますが、
私の学習能力が低いために同じ方法を毎回調べてしまうことが多々あります。
というわけで、使ったことない機能を使ってみて、
操作方法をメモしてみることにしました。

今回はいつもは使用しないけど、ちょっと面白いなと思ったレイヤでの加工方法で
レンズフィルター機能を使ってみることに。
(よく色調補正とかは使いますが、レンズフィルターは使ったことがない。)

ちなみにレンズフィルター機能はレンズを通してフィルムに露光する光の照明のカラーバランスとカラー温度を調整するために、カメラレンズに色付きのフィルターを置き換えるテクニックをまねたものだそうです。カラープリセットを選択したりカスタムカラー調整も可能です。

・PSで加工したい写真を表示します

1

・「新規調整レイヤ」-「レンズフィルター」を選びます

2

3

・適用量を100%にします

5

・「輝度を保持」のチェックを外します

6

・属性で「カスタム」を選択するとカラーピッカーでフィルターの色を選択できます

4

 

ちなみに、アドビのサイトに色々と書いてありますので参考に。

https://helpx.adobe.com/jp/photoshop/using/applying-color-balance-adjustment.html

スクラム研修まとめ③

前回に引き続き用語の説明をしたいと思います。
今回は前回のまとめの中で登場した用語、
・プロダクトバックログ
・スプリント
について書いていきます。

■プロダクトバックログ
プロダクトバックログとはプロダクト(システム)に対する要求の一覧を指します。
・ユーザのニーズ等からプロダクトオーナーが作成する
・1つの要求についてユーザストーリ形式(※)で記述する
・プロダクトオーナー(PO)が開発する順番に並び替える(順番の最終決定権はPOにある)
・要求は可変なので常にメンテナンスして最新の状態に保つ必要がある(優先順位の高いものから開発することでプロダクトの価値を最大化する)
・要求毎に完了の定義を決めておく(デモ手順とその結果を決めておくことでリリース判断可能にしておく)
・開発チームによって見積が行われる(プランニングポーカー(※)という見積手法が主流)

※ユーザストーリ形式
「誰々としてこれこれがほしい。それは何々のためだ」という役割・機能・価値の3つをストーリとして記述する形式

※プランニングポーカー
開発チーム全員でカードを使って行う、複数人の知見を活かした見積の手法。
フィボナッチ級数(1,2,3,5,8)のカードを全員が持ち、基準となるストーリ(要求)とその数字(ポイント)を決めた上で、その他のストーリについて、下記の手順で見積を行う
・対象を個人で頭のなかで見積もる
・一斉に数字が書かれたカードを出す
・差異が出たら、その差異について、まずは最小と最大の数字を出した人が、その根拠を説明する
・それを踏まえて再度カードを一斉に出す
・これを差が少なくなるまで繰り返す(全て一致しなくても差が少なければ、小さい方を採用する)

■スプリント
全体の工期をスプリントという固定の期間に区切って繰り返し開発を行います。
1スプリントの中で実現するストーリをプロダクトバックログの中から決めて(複数可)、リリース判断可能な動くソフトウェアを開発します。
・最大1ヶ月までのタイムボックス
・各スプリントの長さは均一(延長してはならない)
・開発チームはこの期間の中で、計画、設計、開発、テストなどプロダクトのリリース判断に必要な全てのことを行う(ゆえに開発チームは自己組織化されたチームである必要があります)

今回はここまでです。
次回は1スプリントの中で行う具体的な活動について書いていきたいと思います。