我的意思是支持你的观点，因为按我估计实际使用的最大值也只是你的1/25。。。 <- 中国开发网

账号

中国开发网: 论坛: 程序员情感CBD: 贴子 221570

haitao · 2005-10-24 14:57:13 · 阅读: 865

我的意思是支持你的观点，因为按我估计实际使用的最大值也只是你的1/25。。。

主要是强调不是量的问题，就像deadli说的切换马上保存
关键是硬盘灯多闪一下都不爽。。。

像我现在编译delphi或vc，一般尽量使用内存虚拟硬盘保存中间文件的。。。

相关信息:

【技术贴】一个具体的技术实现（多级缓冲）相关的问题，需要形式化 (857字) (haitao [1096] 2005-10-24 22:24)
- 其实数据量又不大，简化程序的考虑还是一切换就马上保存，别判断月份了。 (空) (dead_lee [729] 2005-10-24 22:28)
  - 大是应该不大，每天有1K的备忘，一个月的文件也才30K (16字) (haitao [672] 2005-10-24 22:32)
    - 那就真的要用缓冲了 (空) (nostalgic [630] 2005-10-24 22:33)
    - 这点量，不够硬盘缓存用的。。。 (空) (dead_lee [698] 2005-10-24 22:36)
      - 本来就是看到wallcal利用动态修改背景图来显示这些备忘，很耗cpu、硬盘，不爽才自己作了这个。。。 (15字) (haitao [2086] 2005-10-24 22:38)
        图片动不动就上兆了，你现在这种形式，速度应该很快了。 (空) (dead_lee [802] 2005-10-24 22:40)
- 用数据库吧。我用FireBird写了一个这样的软件自己用。查个东西很方便的。FireBird可以做单机版，也很容易变成网络版 (空) (pcplayer [1071] 2005-10-24 22:30)
  - 拿来一用 (空) (nostalgic [632] 2005-10-24 22:31)
  - .Net用多了后，看到这样的东西。。。 (30字) (dead_lee [848] 2005-10-24 22:33)
    - XML保存东西，效率还是低啊。占空间肯定比数据库多啊。 (空) (pcplayer [832] 2005-10-24 22:36)
      - 那当然，但是用着方便，还是看目标系统的配置了。。。 (12字) (dead_lee [714] 2005-10-24 22:37)
        文件型的东西，和当年的文件型数据库对比，应该有相同的潜在问题：数据量一多，文件一大，容易会有数据文件损坏的危险？ (空) (pcplayer [759] 2005-10-24 22:58)
        当然要看大小了，不超过一兆还是很快的。。 (空) (dead_lee [664] 2005-10-24 23:02)
      - 空间多一点还不算什么 (26字) (haitao [590] 2005-10-24 22:50)
        INI的开销也不小，比SAX只怕有过之无不及。 (空) (GoodHope [597] 2005-10-24 23:25)
        INI的分析算法很简单，开销应该很小的 (10字) (haitao [720] 2005-10-24 23:29)
        你测试过没有？熟归熟，也不能乱说话。 (31字) (GoodHope [784] 2005-10-24 23:37)
        delphi自己的某些字符串操作在字符串较大后是有点低效的，我用faststring (66字) (haitao [1056] 2005-10-24 23:42)
        我说的算法只指Delphi处理INI文件的算法，还没牵扯到Delphi的字符串呢。 (16字) (GoodHope [964] 2005-10-24 23:47)
        Delphi处理INI文件的算法原来就是调用win api的，每读写一个值都要打开关闭ini文件一次的 (40字) (haitao [1084] 2005-10-24 23:48)
        用这种办法读几兆文件…… (空) (GoodHope [0] 今天 23:56) (11字) (GoodHope [818] 2005-10-24 23:59)
        所谓INI，都是只取其定义格式，真正的访问当然是字符串匹配了 (32字) (haitao [759] 2005-10-25 00:03)
        查找不要时间？ (空) (GoodHope [704] 2005-10-25 00:13)
        我的意思是：只要都是到了查找这一级，就是最高效率的了，谁也不会比谁差了 (69字) (haitao [756] 2005-10-25 08:50)
        嘿嘿，TINIFile还谈效率？哈哈哈哈哈哈哈哈！ (36字) (GoodHope [915] 2005-10-25 10:46)
  - 上次下载了一个fb的嵌入版，还没怎么看 (35字) (haitao [779] 2005-10-24 22:33)
    - FB的嵌入版，如果用 DataSnap 来做，很简单的。DBExpress的控件拖一个过来就搞定了。 (空) (pcplayer [790] 2005-10-24 22:38)
      - 乍一看，以为是那个很庞大的express控件集呢 (29字) (haitao [713] 2005-10-24 22:40)
        就是MIDAS。换个名字嘛 (空) (pcplayer [754] 2005-10-24 22:55)
  - 我考虑的网络版，就是作一个连数据库的ISAPI，客户端直接通过http请求访问 (9字) (haitao [703] 2005-10-24 22:48)
    - 如果客户不多，我做网络版连IIS都不要。直接把服务器端写成自己带WEB SERVER的Web Service，输出数据。 (空) (pcplayer [876] 2005-10-24 22:56)
      - 呵呵，这是你的“专利”了。。。我的isapi也是不用iis的。。。 (36字) (haitao [717] 2005-10-24 22:59)
        我都拆成几层了，要换到专业的WEB Server，移植还是很容易滴！ (236字) (pcplayer [745] 2005-10-24 23:08)
  - 刚才又看了一下：Firebird-1.5.2.4731_embed_win32.zip (191字) (haitao [1129] 2005-10-24 23:26)
    - 发此文时，系统报错！！ (2165字) (haitao [817] 2005-10-24 23:46)
    - 大型数据库里的数据都是没加密的。FB要嵌入，只需要一个DLL。如果用MIDAS去连接它，再加一个DLL。总共2个DLL搞定。 (空) (pcplayer [937] 2005-10-25 10:41)
- 一年的数据量能达到十兆的人就是很多事的人了，加上定期清除，根本没必要搞得这么复杂嘛。 (空) (王中王 [830] 2005-10-24 22:36)
  - 1天1K，1年也才400K啊 (54字) (haitao [802] 2005-10-24 22:43)
    - 你把我的话大声朗读十遍，难道我打出来的不是中文嘛？ (空) (王中王 [756] 2005-10-24 22:51)
      - 我的意思是支持你的观点，因为按我估计实际使用的最大值也只是你的1/25。。。 (88字) (haitao [864] 2005-10-24 22:57)
        这么在意硬盘，在退出时统一保存好了。。。 (11字) (dead_lee [681] 2005-10-24 23:01)
        那好像占内存又太大了。。。 (241字) (haitao [840] 2005-10-24 23:09)
        又想马儿跑得快，又想马儿不吃草。 (39字) (GoodHope [859] 2005-10-24 23:27)
        人家有个牛爸爸 (14字) (haitao [654] 2005-10-24 23:30)
        太绝对，太消极了。 (8字) (GoodHope [694] 2005-10-24 23:36)
- 为什么不用4个memo呢？这样你就不用在tab切换的时候去管理缓存了 (空) (tweety [774] 2005-10-24 22:38)
  - 当然，这里有点自我锻炼的意思了。。。 (16字) (haitao [1161] 2005-10-24 22:44)
    - 一直没明白形式化是什么意思。 (空) (GoodHope [1052] 2005-10-24 23:29)
      - 随便找的一个词，不一定准确 (77字) (haitao [743] 2005-10-24 23:33)
        对嘛，你这么一解释 (9字) (GoodHope [1029] 2005-10-24 23:40)
        米吐 (空) (tweety [576] 2005-10-24 23:45)
        。 (空) (ycm0263 [590] 2005-10-25 00:01)
        haitao 可能要说： (47字) (ycm0263 [1040] 2005-10-25 00:06)
- X (44字) (GoodHope [712] 2005-10-24 23:25)
  - 你的是什么机器啊。。。 (19字) (haitao [694] 2005-10-24 23:28)
    - 2600+ (空) (GoodHope [635] 2005-10-24 23:29)
      - 我解析后还要进行数据处理，计算量要比解析XML大多了，一共也才用了500ms。很过分么？ (23字) (GoodHope [819] 2005-10-24 23:34)
        嘿嘿，修改过了。 (9字) (GoodHope [784] 2005-10-24 23:35)
        嗯，有点奇怪。。。我用delphi分析一个应用的日志文件，按每行的某些特征分拆某些列 (60字) (haitao [894] 2005-10-24 23:37)
        多少个Insert啊，不会4000个吧。 (16字) (GoodHope [778] 2005-10-24 23:39)
        是4000个sql，不过每n个提交一次的。。。 (14字) (haitao [1001] 2005-10-24 23:43)
        要不，我们找个东西打个赌，看是SAX读取XML快，还是INI快。 (空) (GoodHope [708] 2005-10-24 23:48)
        你是不是指 Delphi处理INI文件的算法？ (79字) (haitao [711] 2005-10-24 23:49)
        用这种办法读几兆文件…… (空) (GoodHope [618] 2005-10-24 23:56)
        haitao 会死得很爽的。 (空) (ycm0263 [698] 2005-10-24 23:59)
        我是怕goodhope这样比较。。。 (19字) (haitao [1132] 2005-10-25 00:01)
        ╭∩╮（︶︿︶）╭∩╮ (空) (ycm0263 [591] 2005-10-25 00:01)
        古人有：图穷匕现 (9字) (haitao [1102] 2005-10-25 00:04)
        后来delphi5有了一个Tmeminifile吧。。。 (66字) (haitao [957] 2005-10-24 23:59)
        TMemIniFile好不到哪里去 (24字) (GoodHope [942] 2005-10-25 00:08)
        它只是初步避开每次开关ini文件的低效 (18字) (haitao [672] 2005-10-25 08:54)
  - 支持下。。。 (空) (dead_lee [604] 2005-10-25 07:52)
- 没想到这个帖子也能建了这么棵树 (39字) (haitao [591] 2005-10-24 23:56)
  - 你的担心是有道理的。 (114字) (ycm0263 [767] 2005-10-25 00:08)
  - 性能对比 (155字) (GoodHope [754] 2005-10-25 00:22)
    - 你的机器蛤配置啊，如果很高的话，俺心里还能舒坦些，，，俺的测试结果。。。 (196字) (周星驰 [847] 2005-10-25 01:35)
      - 傻子。 (11字) (ycm0263 [665] 2005-10-25 01:55)
        你的测试结果咋样？做智能运算的性能应该也很高，要不路径探索的深度稍微深点恐怕你充电的时候都不能休眠。 (空) (周星驰 [653] 2005-10-25 02:00)
        ╭∩╮（︶︿︶）╭∩╮ (空) (ycm0263 [684] 2005-10-25 02:04)
      - 比你的稍好一点：AMD Athlon64 2.0G (空) (GoodHope [717] 2005-10-25 10:37)
        那还成，我的amd athlon not64的，主频1.0G，超到1400M（或许没超），用3年多的老机器，内存是ddr的，考虑你的可能是双cpu什么的米王级配置，性能当是我的2倍 (15字) (周星驰 [810] 2005-10-25 10:54)
    - Tmeminifile我看过，效率也不算高的 (18字) (haitao [777] 2005-10-25 08:48)

欢迎光临本社区，您还没有登录，不能发贴子。请在这里登录

页面内容处理时间: 0.023 - 617552