与CPython等其他运行时相比,究竟是什么让JVM(特别是Sun的实现)运行缓慢？我的印象是,无论是否需要,它主要与一大堆图书馆的装载有关,但这似乎不需要花费10年的时间来修复.
想想看,JVM的启动时间与Windows上的CLR相比如何？Mono的CLR怎么样？
更新:我特别关注Unix中常见的小型实用程序的用例.Java现在适合这种风格吗？无论Java发生什么样的启动开销,它是否会为每个Java进程加起来,或者开销只是真正体现在第一个进程中？
这里的答案提供了一个手工引用的参考,你想要__ne__返回的东西不仅仅是逻辑逆__eq__,但我无法想象任何这样的情况.任何例子？
我想知道单个文件上的写入是否以原子方式完成,使得写入("bla bla")和后续写入("herp derp")到同一文件中永远不会导致交错,例如"bla herp bla derp" ".假设这些写操作发生在不同的进程或线程中,那么先控制哪些操作？
另外,read()总是返回反映文件的数据,该文件处于完全完成所有先前写入的状态(数据是否已实际写入磁盘)？例如,在写入("herp derp")之后,所有后续读取将始终反映写入文件的完整数据,或者后续读取有时仅反映"herp"而不反映"derp"(或者有时不反映任何数据)在所有)？如果读写在不同的进程/线程中发生怎么办？
我对并发文件访问策略不感兴趣.我只是想知道读写的内容.
要填充具有某些值的序列,这就是我想出的:
(defn pad [n coll val]
(take n (concat coll (repeat val))))
(pad 10 [1 2 3] nil) ; (1 2 3 nil nil nil nil nil nil nil)
我很好奇是否有一个较短的成语,已经这样做,也许更有效率.
1)为了实现真正的低哈希冲突,我是否可以使用sha1的128位中的一半而不是处理sha1本身？我知道这不适用于加密哈希,但我只需要哈希表键的哈希.
2)计算时间不是优先考虑的事项,除此之外我还要挖掘非常小的数据.特别是,我主要是采用2或3个64位哈希并对它们进行散列以获得另一个64位哈希值.为此目的,有比sha1更好的选择吗？同样,碰撞应该是不太可能的.
3)我是一个新手.在sql中使用64位哈希作为id是一个好主意吗？64位id是否会导致sqlite或postgres出现性能问题？我将需要跨多个数据库协调数据(包括Lucene索引),所以我认为我应该直接在表中处理哈希,而不是打扰自动递增的id(这只会在一个数据库中有意义,而不是跨所有数据存储).我认为64位是一个很好的折衷方案:足够大,不可能发生冲突但节省空间(和查找时间？).
4)CRC-64怎么样？这会产生足够随机的分布吗？
我正在处理具有不同宽高比的用户视频.似乎FFMPEG只允许您指定固定的分辨率.我希望输出res适合输入res.同样,我希望FFMPEG能够根据输入视频智能地设置输出比特率:显然它不应该比输入更大.
我可以获得视频的属性,
ffmpeg -i example.flv
但这需要对输出进行一些难看的解析,所以我想知道FFMPEG或其他工具是否有更直接的设施.
基本上,我有Youtube问题:废话进来,合理均匀的质量应该出来.
在我的Solr查询中,我想将最近访问的文档排序到顶部("访问"意味着由用户操作打开).没有其他搜索条件对我有影响:文本与查询匹配的文档中,我希望它们按照最近的使用顺序排列.我只能想到两种方法:
1)在每个文档中包含一个"上次访问"的日期字段以对Solr进行排序.据我所知,Trie Date字段可以很快排序.问题当然是保持该字段是最新的,这将需要存储每个文档的文本,以便我可以删除并重新添加具有更新的"最后访问"字段的任何文档.可变字段可以避免这种情况,但Lucene/Solr仍然不提供可变字段.
2)或者,存储可变的"最后访问"日期并将其更新到另一个数据库中.这将要求Solr返回匹配文档的完整列表,这些文档可能超过数十万个文档.然后,这个庞大的文档ID列表将与db中的日期进行匹配,然后进行排序.它适用于不常见的搜索术语,但不适用于广泛的常见搜索术语.
因此,每次访问文档时,权衡是1)索引大小加上处理成本和2)大查询开销,特别是对于未聚焦的搜索术语
我还有其他选择吗？
在参考关于read()和write()的这个问题时,我想知道每个打开的文件描述是否有自己的读写缓冲区,或者当文件被多次打开时,是否有一个读取和写入缓冲区立刻.我很好奇,因为这会对重叠写入同一文件的确切情况产生影响.也许这在Unix之间有所不同？
(据我所知,"文件描述"是指有关打开文件的信息/选项,例如当前标记位置.相反,"文件描述符"仅指过程中用于引用描述的数字. )
使用lsof命令,我可以确定某个进程是否正在使用某个文件,但是我需要自动检查文件以供使用,并且仅在未使用时才移动它.这些文件正由我无法控制的各种其他程序使用,所以我不能使用咨询锁.目的是阻止其他进程修改该文件,因此只需在进程打开时移动该文件就不行了.有解决方案吗
更新:我认为我认为适合我的目的的解决方案.最终目标是在其他程序完成修改后将这些文件处理为最终状态.如果我将文件移动到另一个目录,我可以使用lsof通过其旧路径检查它是否仍在使用中; 如果是这样,我只是稍后再检查,直到它不再使用,然后处理文件.通过将文件移动到另一个目录,它会隐藏用户和程序中的文件.我不希望用户和程序在旧目录中看到该文件,因为这使他们有机会在我使用lsof和处理文件之间打开文件,这意味着我将以修改状态处理文件.
我对这个回购历史感到困惑。在该页面上，您将看到一个小分支file-content，default即使一个头是另一个头的祖先，该分支也会合并回到该分支。
当我尝试做类似的事情时，除非出现错误消息，否则
file-content分支标记为不活动，未关闭。）
编辑：我的答案中描述了可以与祖先合并的实际条件。
那么这是怎么回事？
我正在加密/解密各种大小和类型的文件,从小文本文件到几GB的视频文件.Pycrypto类只有编码(字符串)作为唯一的编码方法,这意味着我必须将整个文件作为一个大字符串传递(Python 2.7字节/字符串,即).这似乎不太理想.如何以零碎的方式喂养Pycrypto？如果我将文件拆分成块(每个块的大小都是固定数量的块)并使用相同的密钥单独加密这些块,那么这会阻止Cipher Block Chaining吗？(顺便说一下,我正在使用带有256位密钥的AES和每个文件的唯一iv.)
编辑:下面回答了自己的问题,但这引发了另一个问题:使用什么样的块大小？一次一个街区或一次几个街区？任何人都知道一个方便的方法来读取文件,但将其填充到块大小的倍数？