2016-10-01 1 views
2

私は現在ImageProcessorCoreを調べています。私は何かが欠けていると感じる問題に遭遇しました。彼のwebsiteには、私のサンプルプログラムで測定した時とは全く異なるパフォーマンスのベンチマークがあります。私は2.3メガバイト私は(今のところ)幅と高さを取得したいから(3853x2569)のjpg画像を持っているので、私はこの小さな.NETコアコンソールテストアプリケーションを作成しました:ImageProcessorCore:画像を開くには11秒を要しますが、何が欠けていますか?

using ImageProcessorCore; 
using System; 
using System.IO; 

namespace ImageProcessorCoreTest 
{ 
    public class Program 
    { 
     public static void Main(string[] args) 
     { 
      using (FileStream input = File.OpenRead(@"c:\test\a.jpg")) 
      { 
       DateTime start = DateTime.Now; 
       Image image = new Image(input); 

       int w = image.Width; 
       int h = image.Height; 

       double duration = (DateTime.Now.Subtract(start)).TotalMilliseconds; 

       Console.WriteLine("Image size is " + w.ToString() + "x" + h.ToString() + " Pixels (" + duration.ToString() + "ms)"); 
       Console.ReadLine(); 
      } 
     } 
    } 
} 

この操作は以上かかりますイメージを読み込んでサイズを取得するのに、11秒(上記のベンチマークと比較して100倍)が必要です。私は間違って何をしていますか?

私はプロのWindows 10上でバージョン1.0.0を使用している64

(ところで:私のdevのマシンは16G RAMとサムスンProの950のNVMeドライブとi7-5820Kので、おそらくハードウェアがあります私が思うに、ボトルネックになることはできません)

アップデート1:再コンパイルImageProcessorCoreと私はその後、私の(リリースで使用リリースnugetパッケージを作成する)サンプルプログラムは、残念ながら少しだけ超えるまでの期間をもたらします10秒。

更新2:私はちょうど2000x1334ピクセルのテスト画像(外部)のサイズを変更しました。これにより、849ミリ秒までの時間が大幅に短縮されました。デベロッパーのベンチマークで、読み込み、サイズ変更、および書き戻しのために56 msを考慮すると、まだ不思議です。

更新3:テスト用に私があなたと共有できるテスト画像を使用します。新しい画像は11416x6380ピクセル(11.5 MB)で、上記のコードでは17秒以上かかります。あなたはここでそれをダウンロードすることができます:http://orig01.deviantart.net/92d3/f/2010/110/7/2/pla_sf_3_by_recon071.jpg

更新4:私はMyGetリポジトリからパッケージを使用する場合は、最新のテスト画像のための時間は、(アップデート3を参照)を2.4秒にダウンしました。

+0

どのように大きな(test.jpgのための〜3S!)あなたのテストイメージですか? – zaitsman

+0

私は[this](http://orig01.deviantart.net/92d3/f/2010/110/7/2/pla_sf_3_by_recon071.jpg)〜11.5 MBのjpgファイルであなたのコードを試しました。私は、[myget](https://www.myget.org/feed/imageprocessor/package/nuget/ImageProcessorCore)で入手できる_ImageProcessorCore_バージョン_1.0.0-alpha1058_を使用しました。私のマシンは_i5-6200U CPU @ 2です。30 GHz、8 GB RAM、Travelstar Z5K1000ディスクドライブ、Windows 10 Pro 64 bit_を実行します。テスト画像のサイズはあなたのサイズよりはるかに大きいですが、平均で5秒かかります。テストイメージを共有できますか? –

+0

myImageの_ImageProcessorCore_ [パッケージ履歴](https://www.myget.org/feed/imageprocessor/package/nuget/ImageProcessorCore)によると、最後のリリースは_Tue、2020年9月27日に公開されました。あなたのバージョンは、_Sep 30 2016_に掲載されています。他の情報源からそれを収集しましたか?同様にそれを共有することを検討してください。 –

答えて

2

公式のビルドでは適切なパフォーマンスが得られますが、独自のビルドパラメータでは何か問題があることは明らかです。あなたのように、私はImageProcessorCoreをクローンし、自分のパッケージを作りました。当然のことながら、私もパフォーマンスが悪くなっていました。あなたの12.1 MBについてtest.jpgは約23秒かかった(公式ビルドでは3秒かかる)

問題は実際にはビルドコマンドである。既定の.NETコアパッケージコマンド(dotnet pack)は、Debug構成でパッケージをビルドします。デバッグビルドでは、複雑なシンボルストレージやその他の補助操作を実行するため、パフォーマンスが低下します。

私は、次のコマンドを使用してRelease構成でパッケージを構築しました:パフォーマンスは公式のビルドと全く同じである

dotnet pack --configuration Release 

この時間を

+1

良いスポット! ImageProcessorCoreをソリューションの別のプロジェクトとして(別の場所に構築された外部参照dllとして使用するのではなく)リリースモードでソリューションをビルドする場合、同じ効果がありますか? –

+0

これは試していませんでしたが、ビルドエンジンがソースをビルドするために使用している設定に関するものです。現在、ImageProcessorCoreは_.NET Core_ buildエンジンで構築され、_.NET Core_ runtimeを対象としています。 Visual Studioで追加すると、それぞれ_MSBuild_と_.NET Framework_に変わります。どちらのビルドエンジンも 'Debug'と' Release'設定を持っています。しかし、どちらの場合でも、 'Release'ビルドはより良い性能を発揮するといえます。 –

+0

私は今3秒はすべてだと思っています。最終的にはまだアルファソフトウェアであり、 "性能を上げる"というのはdevのロードマップの話題の1つなので、彼の素晴らしい仕事のために彼に感謝したいと思います遠い私は自分自身でコードを微調整するのに十分な経験があるかどうかはわかりませんが、今すぐ試してみます。 – Robert

関連する問題