-サーバ連携方法、オープンソースの使い方など様々なCurlの実際のソースコードの記述方法が集約されています。RTEに非常に大きな性能劣化を起こしているというような問題は今のところありません。これについて、言い切れる根拠は何なのでしょうか?「把握していないだけ」ということではないでしょうか?小職はCurl製品の開発チームです。RTEは内部的にマルチスレッドで動いていますが、その仕組み上で性能問題を抱えていることは、内部で管理しているバグとして、現在のところ存在しておりませんという意味です。ユーザが利用できるサブアプレットでも、性能問題はあがっておりません。おっしゃられる通り、共有メモリとIPCでは速度が違うというのはありますが、それが非常にボトルネックなっているという報告も今のところ受けておりません。(逆にそういった現象があれば、是非報告いただければと思います。)ちなみにCurlの内部的な仕組みは公開しておりませんので、これより深い説明は公開できないことをご了承ください。速度比較しているのもAjax、Flexです。Script)はコンパイルされ、swf形式になります。上記URLの公式情報だけから判断すると「Curlって他のリッチクライアント言語より速いですか?」という質問に対して「速いですよ」は特別誤った回答ではないですよね​?弊社内部では他社製品との比較はもちろん行っております。一般公開できるものではありません。確認したところCurlユーザー企業様ではやはりそういった他社製品との比較を行っているようで、Curlが勝つ部分と.NETが勝つ部分様々なのが正直なところです。われわれとしましてはこのような部分についても今後改善していくようにしていくつもりです。マルチスレッド・マルチコアへの対応についてonyoさんの意見に賛成です。復活の帝王さんは上位設計からの検討に影響が......とかかれてましたが、C/S→Web→リッチクライアントという技術の変遷を辿ると単純にC/Sと同様の考え方(マルチスレッド/マルチコア対応)というのは必ずしも必要でないと思います。現在のシステム構成の傾向は、冗長化あるいはクラウド化したサーバに主処理を集約させておき、クライアントには必要最低限の処理を行わせるのが一般的に思います。リッチクライアントが出てきた当初はここまでサーバの処理能力が上がると思われていませんでしたから、クライアントが行う処理を増やす設計を行う事がリッチクライアントアプリケーションに必要でした。現在は、いわゆるビジネスロジックはサービス化してサーバ側ににおいて、クライアントはそのやりとりとGUIだけに特化させる考え方を取る方が開発の効率も良いと思います。した時に、別に難しいスレッド管理で複雑な処理を考えなくても非同期通信などで事足りるCurlは必要十分な機能を満たしていると思います。最近.Netで別にスレッド管理するプログラムを構築したことはありません。非同期通信や非同期のプロセス呼び出しなどで大概の事が実現できるため、Curlも.Netもあまり大きな違いは感じないと思います。(Curlは以前は出来なかったようですが、Ver8から非同期のshell実行も出来るようです。上記の視点(クライアントの処理をGUIに特化させる)で考えた時に体感出来るほどの処理速度の違いは無い様に思います。どちらかと言うとCurlの方が遅いかもしれませんが、その分Curlはマルチプラットフォーム、サーバ非依存という性質を持っています。.NetはあくまでWindowsのみ、かつバージョンにより対応OSも細かく分かれますのでその点は不利と言わざるを得ないかもしれません。ニュートラルな立場で意見を申しますとテクノロジーというか、開発環境においては.Netの方が優れていますね。Studioでの開発において、プログラミングの必要な箇所をほぼビジネスロジックのみに集約できるのは素晴らしいの一言に尽きます。Curlは.Netと比べAPIの豊富さや柔軟さはありますが、どうしてもレイアウトの調整やイベントの設定など細かな所でプログラミングが必要ですから、その点は劣っていると思います。集団開発における開発の自動化と効率化については様々な考えがあり、一概にどちらが正しいとは言いかねるのですが。StudioにもCDEにも一長一短あると思います。マルチスレッド・マルチコアへの対応についてonyoさん、hokadaさん返信ありがとうございます。>onyoさん今回の背景にあるのは、あるアプリケーション(Win32ネイティブ)を移行するにあたり、Curlで作成したら?との仮定からです。私個人は「もとがローカルアプリなんだから、EXE作れば(=Windowsフォームで作る)良いんじゃないの?」との思いだったのですがCurlでは無理なのか?という話から検証している次第です。Windowsフォームで作るのとどういう違いが出てどういうアドバンテージがあるのか?何が苦手なのか?を調べている途中です。前提が伝わっていなくて申し訳ありません。ちなみに私は.NETでのGUI開発において、スレッドがなければ話にならなかった事を逆に経験しています。他に実現手段がないのか?という点については精査していません。>hokadaさん書き込み内容からもしかして?とは思っていましたが、中の人(?)ということでしたか。Flexの件は失礼しました。一応調べたのですが、使ったことがなかったので・・・ごめんなさい。一般公開の件も企業秘密(?)ということでしたら仕方ありません。最後に中の人と知っての話ですが。実際にCurlで作られているシステムをこの2年担当している者としては機能的な面、速度的な面、開発者視点、において.NETでの開発と比べ期待を裏切られた事が多々あります。こちらから公式に問題として挙げていないということもあるかと思いますし、こちらの作りが悪いことに起因することもあるかと思います。.NETで作った過去のシステムだと始末書ものの問題、品質が挙がっていることも事実です。(エンドユーザが違うからなのですが)(レアケースかもしれませんが)中の人が知らない(いや、ご存じなのかもしれませんが)問題もユーザサイドで起こっていることをご留意頂ければ幸いです。体感出来るほどの処理速度の違いは無い様に思います。これは現在の流れがそう、という事からそう言われていますが「現在の流れがそうだから、クライアントの処理をGUIに特化させる」というシステムサイドの要求が通るかは不明であり「だから違いはないだろう」という話の進め方にはいささか違和感を覚えます。その点は不利と言わざるを得ないかもしれません。Windowsのみ、という点はその通りですが、意地悪な言い方をすれば「現在のクライアント側の構成は、Windowsが主流であり、Linuxなどはサーバ側のOSが主であると一般的に思います。」となり「マルチプラットフォームという点を挙げられていますが、上記の視点で考えた時にそれほどの違いは無い様に思います。(レアケースかもしれませんが)中の人が知らない(いや、ご存じなのかもしれませんが)問題もユーザサイドで起こっていることをご留意頂ければ幸いです。逆に、いろいろなニーズや問題点などをいただけると、今後製品の方向性を検討する材料としていけるので助かります。いったニーズの収集もこのコミュニティサイトを立ち上げた理由の一つです。今後ともよろしくお願いいたします。マルチスレッド・マルチコアへの対応について復活の帝王さん、onyoさん、nmyzkさんはじめまして。マーケティングの三野と申します。皆さま、貴重なご意見ありがとうございます。速度比較についてはいつもついてまわりますね。本線とはそれるかもしれませんが、別視点で「速度」についてコメントさせていただきます。Curlの思想はもともと「Web上でクロスプラットフォームでハイパフォーマンス動作する」という思想のもと作られています。その思想のもと、考えられたのが、「Curl言語」、「JITコンパイル方式」、また「ソースコード配信」です。メリットとしてはソースコードベースなのでクライアントへのモジュールのサイズが小さいことや1つのソースで管理できることなど様々あります。そのため、サイズは通信速度に依存してくるため、通信速度が様々な場合、.NETアプリケーションとCurlアプリケーションでの初期起動の場合は圧倒的にCurlのほうが「速い」です。RTE」1つで様々なプラットフォームを吸収しているためのコスト(ここは内部仕様なので詳しく話せませんが)など「アプリケーションが起動するまでの「速度」」に関してネイディブのアプリケーションと比べると若干遅い場合があるのは認識しています。この部分についても2回目以降の起動を「速く」するため、パッケージキャッシュの機能をCurlは用意しています。ちなみに.NETアプリケーションはやはり「ネイティブアプリ」と認識しており、リッチクライアントのカテゴリに入ってはいるものの「ノータッチデプロイメント」、「UpdaterApplicationBlock」を経て(前記2つの方式は問題あったようです。)、「ClickOnce」という技術を用いて1クリックでインストールができるようになっただけと認識しております。Hell」問題を解決するために出てきたと思いますが、出てきた当初はアプリケーションのモジュール単位の更新ができないなど問題など様々あったと思います。Side機能」などによって解決されていると思いますが。.NETはやはり「Windows」依存があると思いますが、その.NETの世界をWebへ持ち込むコンセプトで打ち出されたのが「SilverLight」です。以前MS、Adobeの方とディスカッションする機会があるときにそう言っておりました。RTE」はインストールする必要がありますが、ユーザーが作ったCurlアプリケーションは「インストール」されるわけではありません。通常はメモリ上に展開されるだけです。Ver4以降、オフラインでの利用も考慮し、新たに「OCC(随時接続コンピューティング)」の機能を追加したのもありますが、それはCurlのセキュリティポリシーを保ったうえでのアーキテクチャになってます。RTE」という1つのプラットフォームで「ネイティブアプリケーション」「Webアプリケーション」のどちらともの「いいところ」を取り入れていこうと考え、拡張しております。それを「Curl言語」という1つの言語で開発できることもメリットだと考えています。RTE」では実現不可能な部分については新たなプラットフォームが必要であるとも考えており、研究開発しております。「ネイティブアプリケーション」と比較しても負けないだけの「パフォーマンス」は常に追求していくつもりです。いった意味でも引き続き、貴重なご意見よろしくお願いいたします。