◀一般トップへ
  • 1885 うーん、保存が遅いかもしれない・・・?
    • 1886 Re: うーん、保存が遅いかもしれない・・・?
      • 1888 Re2: うーん、保存が遅いかもしれない・・・?
        • 1889 Re3: うーん、保存が遅いかもしれない・・・?
          • 1890 Re4: うーん、保存が遅いかもしれない・・・?
            • 1897 VSSの使い方?
              • 1901 Re:VSSの使い方?
        • 1903 Re3: うーん、保存が遅いかもしれない・・・?
          • 1904 Re4: うーん、保存が遅いかもしれない・・・?
            • 1905 Re5: うーん、保存が遅いかもしれない・・・?
              • 1913 Re6: うーん、保存が遅いかもしれない・・・?
                • 1915 Re7: うーん、保存が遅いかもしれない・・・?
                  • 1918 Re8: うーん、保存が遅いかもしれない・・・?
                • 1922 Re7: うーん、保存が遅いかもしれない・・・?
                  • 1927 Re8: うーん、保存が遅いかもしれない・・・?
            • 1968 Re5: うーん、保存が遅いかもしれない・・・?
  • [1885] うーん、保存が遅いかもしれない・・・? Youma 2002年05月21日 22:04

    どうも、Youmaです。

    私の環境だけかもしれないのですが、
    Sakuraの文書保存速度がちっとばっかし遅い気がします。

    メモ帳に保存速度で負けるのは仕方ないっすが、
    Visual Studio .netなんて糞重たいエディタにも
    保存速度で負けててちょっとショック(TT)

    レスポンス的にはSakuraで全角文字3個程度を編集した際、
    CTRL+S等で上書き保存した時、下手すると5秒~10秒掛かる。
    …早くても1秒。

    これが、メモ帳/VS.netだと、計測出来ない速度。
    (メモ帳が当然ながら最速。VS.NET等も1秒は掛からない。)

    …まぁ、保存先が悪いってのが大きな要因だとは思いますが。

    (ネットワークドライブの割り当て…で出来ている
     LAN上の別マシンに保存する際に、保存速度の差が顕著に現れます)

    癖で、ちょくちょく上書き保存してしまう性質なので、
    この数秒間のロスがちっと痛い(TT)

    …で、質問です。
    現在、SAKURA Var 1.3.1.4を使っていますが、
    保存時のレスポンス向上に必要な設定とかってありませんか?

    ○とりあえず、バックアップの作成というオプションは切りました。
    (以前、複数世代のバックアップ作成してたら、酷い事になったので(当然ですが)
     最終的に落ち着いた設定はゴミ箱へ直行/一世代のみ(.BAK) でした。
     現在はそれもOFFにしていますが、これは怖いので取っておきたい --;)

    他に、保存時のレスポンスに関係しそうな設定項目が思いつかなくて…

    よろしく、ご教授お願いいたします。
    • [1886] Re: うーん、保存が遅いかもしれない・・・? げんた 2002年05月21日 22:24

      >私の環境だけかもしれないのですが、
      >Sakuraの文書保存速度がちっとばっかし遅い気がします。
      先日、隠しファイルとシステムファイルの編集を行えるようにするために
      * 属性変更
      * ファイルの書き込み
      * 属性戻す
      の3ステップを行うように変更されたのですが、属性変更に時間がかかっているのかもしれませんね。
      • [1888] Re2: うーん、保存が遅いかもしれない・・・? こおり 2002年05月22日 05:00

        こんばんは。

        > 先日、隠しファイルとシステムファイルの編集を行えるようにするために
        > * 属性変更
        > * ファイルの書き込み
        > * 属性戻す
        > の3ステップを行うように変更されたのですが、属性変更に時間がかかっているのかもしれませんね。
        これって確かAPIを直接使えば属性変更は必要ないけど遅くなる、
        ということでしたよね。

        だったら、APIと独自のバッファを組み合わせて使えばいいんじゃないかと思い、
        試しに作ってみました。
        http://www.egroups.co.jp/files/sakura-editor/Developer/Source/WriteFileByAPI.lzh

        でも、ほとんど変わっていないような気が....。
        • [1889] Re3: うーん、保存が遅いかもしれない・・・? げんた 2002年05月22日 06:15

          >APIと独自のバッファを組み合わせて使えばいいんじゃないかと思い、
          とりあえずは、隠し属性やシステム属性がなければ属性変更をSKIPするので十分だと思います。ネットワークドライブにある隠しファイル・システムファイルは遅くてもあきらめてもらう(^^;)。で、相変わらず遅いなら原因は別のところにあることになりますね。
          • [1890] Re4: うーん、保存が遅いかもしれない・・・? Youma 2002年05月22日 10:41

            ▼ げんたさん
            > >APIと独自のバッファを組み合わせて使えばいいんじゃないかと思い、
            > とりあえずは、隠し属性やシステム属性がなければ属性変更をSKIPするので十分だと思います。
            > ネットワークドライブにある隠しファイル・システムファイルは
            > 遅くてもあきらめてもらう(^^;)。
            > で、相変わらず遅いなら原因は別のところにあることになりますね。

            うわぁ~、皆様、いろいろとありがとうございます。
            早速試しに作っていただいたSAKURAを実行! と思いきや、
            C++のソースでした(TT)

            プログラマ一年生とはいえ、コンパイルする環境すらないのが
            お恥ずかしい限りです。

            情けない話ですが、とりあえず、現状維持で頑張ってみます。
            …次回リリース時、隠し属性関連が組み込まれてるとうれしいなぁ。

            <それで遅いなら、本当に私の環境が変なだけかもしれないですが。
            <特に、うちの会社はVSSを使ってソース管理してるので
            <ファイルに隠し属性等が沢山付いていそうですし…マイクロソフトだし。

            (癖になっている一行書き終えたらCTRL+Sを押す…という
             操作を、CTRL+ALT+Sに変更して無意識の上書き保存をしなくしたら
             大分、開発速度があがりました(^^;)
             <無駄に上書き連発するので大間違いの修正をしたとき、
             <その日の途中までの状態に戻せなくて
             <酷い目にあってしまうんですよねぇ。
             <それも、改善するかも
            • [1897] VSSの使い方? げんた 2002年05月22日 18:26

              ><特に、うちの会社はVSSを使ってソース管理してるので
              VSSでソース管理しているなら、リポジトリだけがネットワークドライブで作業領域はローカルディスクにあるような気がしますが。なんか使い方が変?

              > <無駄に上書き連発するので大間違いの修正をしたとき、
              > <その日の途中までの状態に戻せなくて
              > <酷い目にあってしまうんですよねぇ。
              > <それも、改善するかも
              これも、VSSから過去のバージョンを取り出すのが筋かと...個人で勝手にブランチを作ってそこで作業するのは禁止されてるのかな?
              • [1901] Re:VSSの使い方? Youma 2002年05月22日 19:14

                ▼ げんたさん
                > ><特に、うちの会社はVSSを使ってソース管理してるので
                > VSSでソース管理しているなら、リポジトリだけがネットワークドライブで作業領域はローカルディスクにあるような気がしますが。なんか使い方が変?
                >
                > > <無駄に上書き連発するので大間違いの修正をしたとき、
                > > <その日の途中までの状態に戻せなくて
                > > <酷い目にあってしまうんですよねぇ。
                > > <それも、改善するかも
                > これも、VSSから過去のバージョンを取り出すのが筋かと...個人で勝手にブランチを作ってそこで作業するのは禁止されてるのかな?

                ん~、うちは随分変な使い方してると思いますよ(W

                Webの公開用フォルダ(の試験用) = 作業フォルダ

                ですもん(W これだと、作業結果を直でIE等でチェックできるからかな?

                過去のバージョンを取り出し~ってのは私の使い方の粗雑さですね。

                朝:チェックアウト
                一日中弄りとおし、
                夜:帰るときにチェックイン

                …なんて事してますんで、朝~夕方あたりまで
                ずーっと作業してて、ふときづいたら構造的にバグバグに
                なっちゃった…ってな時、朝の状態までファイルが戻るんですよ。
                おそらくVSSにはきちんと公開させる為の機能があるのだろうが、
                うちじゃ、作業フォルダの中身を直接FFFTPで…(--;)
                (※そのおかげでVSSの機能の「同期」とかが使えん)

                ま、そんな訳でファイルの保存先がLAN越しになっちゃうんですよねぇ。

                運用的にも問題がありありですねぇ。 自分で鯖立てて其処で開発ってのも
                他のソースとの絡みで難しそうだし…
                作業中の保存だけ早くする方法ってないかなぁ?

                (SAKURAと同時期にOS自体をXPに変えた為って気がしないでもない。
                 時折、LAN等関係なしに、一瞬フリーズっぽい状況に陥る気がします。<XP)
        • [1903] Re3: うーん、保存が遅いかもしれない・・・? すい 2002年05月22日 21:55

          >http://www.egroups.co.jp/files/sakura-editor/Developer/Source/WriteFileByAPI.lzh
          >
          >でも、ほとんど変わっていないような気が....。

          ファイルを close する直前にバッファの Flush をやっていますが、コレ、意味無いのでは?

          というか、ファイル書き込み後にバッファ Flush をネットワーク上で実行するとトラブルが出る事があるらしひので積極的にやめる方向で(笑)お願ひ。m(_ _)m
          ↓Jp288794 参照
          http://www.microsoft.com/japan/support/faq/KBArticles2.asp?URL=/japan/support/kb/articles/jp288/7/94.asp

          他の人が後々追加したりしないように注釈文も入れておくと、なおgood。
          オリジナルの方でも fflush(); とかやってますね。これ取るだけでどう?(変らん可能性大)
          • [1904] Re4: うーん、保存が遅いかもしれない・・・? こおり 2002年05月23日 01:12

            > オリジナルの方でも fflush(); とかやってますね。これ取るだけでどう?(変らん可能性大)
            おおっ!!
            fflushを取ってみたら、今まで一秒ぐらいかかっていた小さなファイルの保存が一瞬でできるようになりました。

            それにしても、fflushにこんな問題があるとは....。
            勉強になりました。

            ちなみに、そのソースと実行ファイルです。↓
            http://www.egroups.co.jp/files/sakura-editor/Developer/Source/no_fflush.lzh
            http://www.egroups.co.jp/files/sakura-editor/Developer/Source/no_fflush_exe.lzh
            • [1905] Re5: うーん、保存が遅いかもしれない・・・? Youma 2002年05月23日 10:08

              ▼ こおりさん

              おお! exeだぁ~。 という事で早速実行して見ました。
              ネット越しだと、まだもたつきがあるけど、
              当社比1.5倍程早くなったような気がしませう。

              ローカルフォルダに対する保存速度はさらに速くなって
              人間の感覚ではメモ帳との違いがわかりませんです♪

              LAN上への保存は…、これはOSを変えてから急に浮上した
              (今まで気が付か(しな)なかったからなぁ。)
              気もするんでどっか、そこらへんに実問題があるかもと、
              ちょっと調べてみようかと。(といっても、Win2kマシンに
              SAKURA乗せてチェックするだけだけど。)
              • [1913] Re6: うーん、保存が遅いかもしれない・・・? すい 2002年05月23日 20:16

                ▼ こおりさん
                >fflushを取ってみたら、今まで一秒ぐらいかかっていた小さなファイルの保存が一瞬でできるようになりました。
                あらま。それはラッキーです。:-)
                fflush の説明読むと、あたかも「fflush 実行時点でディスクに書き込みが行われる」ような誤解を受けるけど、実際にはいくら fflush を実行してもディスクに対する書き込みの類は全く行われない関数なのでディスク書き込み処理時に使うだけ無駄なわけで、その上に OS によってはデッドロックを引き起こす致命的バグがあるとなるとますます使いたくない 1000害あって1利無しの関数だから削除して欲しかったのですが(長い(^^;)、結果からすると何か中(メモリ上)で余計な事を一生懸命ゴニョゴニョやってるんですね。:-P

                でも
                ▼ Youmaさん
                >当社比1.5倍程
                って事は、まだ VS.NET とかに負けてる?って事でしょうか?
                あとは、やっぱり げんたさん がおっしゃるように属性変更がらみ?確かにネットワーク経由だと、ちょいと時間喰う処理かと。
                WriteFile 中での GetFileAttributes , SetFileAttributes の回数を減らす工夫をして見るとか。

                ・GetFileAttributes って先頭で1回実行するだけで、あとは取得値を使い回すんじゃダメ?(私はダメかどうかわからないもので)
                ・SetFileAttributes も dwFileAttribute の値を見て、必要がある場合(隠し属性の場合とか)のみ実行する。

                通常属性の場合:先頭で GetFileAttributes を1回実行するのみ。
                隠し属性の場合:↑の他、必要箇所で SetFileAttributes を実施。
                をとりあえずの目標に。
                ↓あくまでイメージですが。(試していません。このままじゃマズいかも。m(_ _)m)
                ◎843行
                // ファイル属性を取得する。
                DWORD dwFileAttribute;
                dwFileAttribute = ::GetFileAttributes(pszPath);
                if ( dwFileAttribute == (DWORD)-1 ){
                dwFileAttribute = FILE_ATTRIBUTE_NORMAL; //@@@ 2002.04.15 MIK
                }
                else{
                if ( dwFileAttribute & (FILE_ATTRIBUTE_HIDDEN|FILE_ATTRIBUTE_SY
                STEM) ){
                // 読取専用属性だけ残す(ノーマル属性が付いていたらそれも残す)。
                ::SetFileAttributes(pszPath, dwFileAttribute & (FILE_ATTRIBUTE_READONLY|FILE_ATTRIBUTE_
                NORMAL));
                }
                }
                <<<中略>>>
                ◎881行。
                書き込みエラー時の処理だから、ここは保存速度に影響しないはずなので変更無し。ただ、現状でも先頭の方で dwFileAttribute == -1 なら dwFileAttribute = FILE_ATTRIBUTE_NORMAL; しているから、ここの if 判定は無駄。スッキリさせとく。
                //<< 2002/04/13 Azumaiya
                // ファイル属性を元に戻す。
                ::SetFileAttributes(pszPath, dwFileAttribute);
                <<<中略>>>
                ◎1038行。書き込み完了後の処理
                //fflush( sFile );/* add */ // 速度低下する&環境によってはデッドロックするから削除
                fclose( sFile );/* add */
                //<< 2002/04/13 Azumaiya
                // ファイル属性を元に戻す。
                if ( dwFileAttribute & (FILE_ATTRIBUTE_HIDDEN|FILE_ATTRIBUTE_SY
                STEM) ){
                ::SetFileAttributes(pszPath, dwFileAttribute);
                }
                //>> 2002/04/13 Azumaiya
                  <略>
                ↓削除
                // dwFileAttribute = ::GetFileAttributes(pszPath);
                // if ( dwFileAttribute == (DWORD)-1 )
                // {
                // dwFileAttribute = FILE_ATTRIBUTE_NORMAL;
                // }

                どおでしょ?
                • [1915] Re7: うーん、保存が遅いかもしれない・・・? すい 2002年05月23日 20:33

                  >あとは、やっぱり げんたさん がおっしゃるように属性変更がらみ?確かにネットワーク経由だと、ちょいと時間喰う処理かと。
                  >WriteFile 中での GetFileAttributes , SetFileAttributes の回数を減らす工夫をして見るとか。
                  あらま。今、こおりさん の新しいソースをダウンロードしてみたのですが既に↑と同等の事はやってるんですね。
                  って事は...?もう限界? :-)
                  後は何でしょ。
                  • [1918] Re8: うーん、保存が遅いかもしれない・・・? Youma 2002年05月24日 10:01

                    ▼ すいさん
                    > >あとは、やっぱり げんたさん がおっしゃるように属性変更がらみ?確かにネットワーク経由だと、ちょいと時間喰う処理かと。
                    > >WriteFile 中での GetFileAttributes , SetFileAttributes の回数を減らす工夫をして見るとか。
                    > あらま。今、こおりさん の新しいソースをダウンロードしてみたのですが既に↑と同等の事はやってるんですね。
                    > って事は...?もう限界? :-)
                    > 後は何でしょ。

                    うーん、何なんでしょう?
                    とりあえず、ローカル環境への保存は、メモ帳程ではないけど、
                    VS.NET等よりは、軽快な感じになりました。
                    (保存時の速度差は計測出来ないので、全体的に勝ってます)

                    …ネットワーク越しだと、やっぱ、勝負にならないですねぇ(TT)
                    秒単位で時間が掛かっているようです。

                    仕事の合間を見て(隙を見て??)Win2000マシンに
                    SAKURAをぶちこんで(Serverマシンだったりする(--;))
                    LAN越しの速度差を調べてみます。
                    …ので、結果は少々お待ちください。(ペコリ)

                    …WIN2000にて、問題がなかったとすると、XPのLANは、
                    デフォルトの設定(LANはXP任せで設定したので)だと、
                    遅い…と、暫定的に決め付けてしまおうかなぁ。
                    (その辺のハード系の設定は全然わからんのでお手上げです)
                • [1922] Re7: うーん、保存が遅いかもしれない・・・? みく 2002年05月24日 18:37


                  >WriteFile 中での GetFileAttributes , SetFileAttributes の回数を減らす工夫をして見るとか。

                  ファイルクローズ後、タイムスタンプを取得するために
                  ファイルを再オープンするのですが、このとき
                  GetFileAttributesを実行してます。
                  これは最初に実行したGetFileAttributesと同じはずな
                  のでCWriteFileクラスからdwFileAttributeを取得でき
                  るようにすればよいのではないでしょうか。
                  (新規ファイルのときはNORMALにする必要ありですが)
                  • [1927] Re8: うーん、保存が遅いかもしれない・・・? こおり 2002年05月24日 23:02

                    なるほど、と思って改めてソースを見たのですが、これって属性を取得する必要があるんでしょうか?

                    MSDNライブラリのCreateFileの説明には

                    既存のファイルを開く場合、
                    &#8226;dwFlagsAndAttributes パラメータで指定されたフラグに、既存のファイルの属性を組み合わせます。

                    と書いてあるので、CreateFileの引数にはFILE_ATTRIBUTE_NORMALを指定すれば十分なような気がするのです。
                    試しに隠し属性をつけたファイルを保存してみても、属性を変更してしまうことはありませんでした。
            • [1968] Re5: うーん、保存が遅いかもしれない・・・? やざき 2002年06月04日 21:51


              >ちなみに、そのソースと実行ファイルです。↓
              >http://www.egroups.co.jp/files/sakura-editor/Developer/Source/no_fflush.lzh
              >http://www.egroups.co.jp/files/sakura-editor/Developer/Source/no_fflush_exe.lzh

              こいつを取り込みましたー。