能力值：
( LV6，RANK：90 )
|
-
-
2 楼
这种大文件访问很慢的，基本上大部分时间都消耗在I/O上，能用缓存并使用有效的数据结构就尽量去用。打开文件的时间是没什么必要要考虑，如果你读取的内容很多的话
|
能力值：
( LV2，RANK：10 )
|
-
-
3 楼
哦，大部分时间消耗在I/O上，小文件不也有I/O操作码？就算采用缓存的话，查找起来是不是也非常耗时啊？其实我想做这样的实验，就是找不到这样大的文件来尝试。
|
能力值：
( LV6，RANK：90 )
|
-
-
4 楼
查找有平衡树/B树/Hash表等方法降低耗时
|
能力值：
( LV2，RANK：10 )
|
-
-
5 楼
呵呵，我的问题不是这个意思了。一个大文件和一个小文件访问时间的区别具体在哪里？是不是相差很大呢？这个访问不仅仅是打开了，因为里面是一条条策略，要匹配的。
|
能力值：
( LV6，RANK：90 )
|
-
-
6 楼
打开时问题，在于你读取磁盘的时间
|
能力值：
( LV2，RANK：10 )
|
-
-
7 楼
其实我要证明一件事：给你一条策略，从一个非常大的文件中匹配这条策略所耗费的时间远远大于一个小文件。1这是否正确？2具体原因或者依据？
|
能力值：
( LV6，RANK：90 )
|
-
-
8 楼
取决与你文件的组织方式，如果足够好的话，可能只会慢一点。
我前面的说法都是建立在你需要读取很多文件中内容才能确定匹配情况下，就会慢
|
能力值：
( LV3，RANK：20 )
|
-
-
9 楼
楼主要把问题说得具体点，因为像查找数据，可以通过索引来解决，所以和文件大小关系不大，但如果你要读的数据一点规律都没有，那可就找得特慢。
|
能力值：
( LV2，RANK：10 )
|
-
-
10 楼
liuyq和你的说法应该是一致的吧？我的策略文件没有考虑组织方式，就是一条条策略，打开之后就要匹配，这样的话就很慢。
我还有一个问题：就算组织方式再好，无论是hash等，我感觉也要慢好多吧，毕竟数量级差距很大。不知道selinux的策略组织方式是什么样子的？
|
能力值：
( LV2，RANK：10 )
|
-
-
11 楼
如果你在做这方面的开发，给你个建议，策略分组，每组一个文件，以后维护更新都很方便
搞到一个文件的结果，很可能是，第一条错了，后面99999条全读不出来，而且检索也会累死人，大部分时间都浪费在检索上了
|
能力值：
( LV2，RANK：10 )
|
-
-
12 楼
不是研究这方面的东西，想知道访问时间差距是否很大，想自己做实验，但是没有这么大的文件来做实验。据我所知，selinux的策略库几十万条，但是不知道访问起来是不是很慢，还是人家用了特别的组织方法。
|
能力值：
( LV3，RANK：20 )
|
-
-
13 楼
自已写个程序，创建一个大文件件，写入随机数就可以了
|
能力值：
( LV2，RANK：10 )
|
-
-
14 楼
还是挺麻烦的，一条策略会很长。知道原理就行了。 
|
能力值：
( LV3，RANK：20 )
|
-
-
15 楼
编程的人怕麻烦，劝你还是去做民工
|
能力值：
( LV2，RANK：10 )
|
-
-
16 楼
我就是it民工啊，呵呵。
|
|
|
|
