由于我不确定如何表达这个问题,我将用一个与我想要实现的非常相似的例子来说明它。
我正在寻找一种方法来优化执行以下任务所需的时间。
假设我有三组标有“A”,“B”和“C”的数字,每组包含任意数量的整数。
我收到一堆订单,要求提供一个数字“包”,每个订单要求一个特定的整数组合,每组一个。因此,订单可能看起来像“A3,B8,C1”,这意味着我需要从集合A中获取3,从集合B中获取8,从集合C中获取1。
任务很简单:抓住订单,查看数字,然后收集它们并将它们放在一起“打包”。
我需要一段时间来收集这些数字,并且通常会有一个订单要求与之前订单相同的数字,所以我决定存储所有的包以供以后检索;这样,我处理重复订单所需的时间就会大大减少,而不必再去收集相同的数字。
收集号码所花费的时间很长,但如果我当天收到大量订单,则不能一个接一个地检查每个包裹。
例如,如果我有以下几组数字和订单
set A: [1, 2, 3] set B: [4, 5, 6, 12, 18] set C: [7, 8] Order 1: A1, B6, C7 Order 2: A3, B5, C8 Order 3: A1, B6, C7
我会把订单1和2的包装在一起,但后来我注意到订单3是一个重复的订单,所以我可以选择将我为第一个订单放在一起的包装并快速完成最后一个订单。
目标是优化处理一摞订单所需的时间。目前我已经提出了两种方法,但也许可能有更多的方法来做事
收集每个订单的数字,无论它是否重复。我最终得到了很多包裹,而且对于有人为50个相同的包装订购批量订单的极端情况,这显然是浪费时间
检查包是否已存在于缓存中,可能在订单上使用某种散列方法。
有什么想法吗?
答案 0 :(得分:1)
不知道确切的时间是不可能确定的,但它看起来好像你的想法2,使用某种哈希表存储以前的订单是要走的路。
答案 1 :(得分:1)
关于如何获取数据以组成包等,没有太多细节。这使得很难为您的问题找到不同的解决方案。例如,现有的软件包可能会引导您创建新软件包所需的数据,尽管它们在某种程度上有所不同。为此,实际上有专门的散列方法,如Locality Sensitive Hashing。
考虑到你提出的两种方法,去路线2听起来很自然。索引中的哈希听起来微不足道(第一顺序很容易通过数字167识别,或字符串“167”,对吗?)因此你使用哈希没有任何真正的缺点。也许内存限制因为你需要保持旧包装。还有一些常用的方法可以定义要保存在(散列)缓存中的哪些包以及要丢弃哪些包。