检查两个字符串是否是Java中的排列(Hashmap与阵列的效率)

时间:2015-11-01 03:47:31

标签: java hashmap big-o

我正在阅读一本编码书,试图更多地了解Java,并遇到了这个问题。

问题是:“给定两个字符串,写一个方法来判断一个是否是另一个的排列。”

仔细研究了一分钟后,我决定使用Hashmap解决方案。我的逻辑是添加,删除和搜索都是O(1),因此它是一个快速的解决方案。我的代码如下:

    public static boolean isPermutation(String a, String b) {
    if(a.length() != b.length()) {
        return false;
    }
    HashMap<Character, Integer> map = new HashMap<Character, Integer>();
    for(int x = 0; x < a.length(); x++) {
        char letter = a.charAt(x);
        if(!(map.containsKey(letter))) {
            map.put(letter, 1);
        }
        else {
            int val = map.get(letter) + 1;
            map.put(letter, val);
        }
    }
    for(int y = 0; y < b.length(); y++) {
        char letter = b.charAt(y);
        if(!(map.containsKey(letter))) {
            return false;
        }
        else {
            int val = map.remove(letter) - 1;
            if(val > 0) {
                map.put(letter, val);
            }
        }
    }
    return true;
}
然而,这本书使用数组作为答案。

public boolean permutation(String s, String t) {
    if (s.length() != t.length()) {
        return false;
    }
    int[] letters = new int[256];
    char[] s_array = s.toCharArray();
    for (char c : s_array) {
        letters[c]++;
    }
    for (int i = 0; i < t.length(); i++) {
        int c = (int) t.charAt(i);
        if (--letters[c] < e) {
            return false;
        }
    }
    return true;
}

我有三个问题。

首先,我想知道我的实现是否效率低于本书 - 如果是,那么低效率是什么,以及是否可以纠正它们以使Hashmap实现更好(或至少相等)给定的数组实现。

其次,据我所知,我的Hashmap使用自动装箱将字符转换为字符。自动装箱是否会出现明显的减速?

第三,在我的代码中,我试图避免使用Hashmap的remove()函数。我的逻辑是,虽然它理论上应该删除O(1),使用put()代替现有的密钥替换新的密钥(在这种情况下,覆盖旧值)会更有效,因为替换将是比删除,然后添加更便宜。我的逻辑是否正确?这是我应该做的事情吗?

非常感谢!

1 个答案:

答案 0 :(得分:3)

首先观察:大哦符号不是衡量表现的标准。相反,它表明算法将如何扩展,因为变量(例如N)倾向于无穷大。

  

首先,我想知道我的实施是否效率低于本书......

对他们进行基准测试!说真的,仅仅通过检查代码就很难说哪种方法会更快。

您的基准测试需要考虑到相对性能取决于输入的事实;例如用一系列不同的弦长来测量。

  

......如果是这样,效率低下的是什么......

这是剖析的用途。它会告诉你每种方法花了多少时间。有些分析器可以测量到行号的级别:

  

...以及它们是否可以更正,以便Hashmap实现与给定的数组实现更好(或至少相等)。

这是为了让你弄明白......一旦你进行了基准测试和分析。

  

其次,据我所知,我的Hashmap使用自动装箱将字符转换为字符。自动装箱是否会出现明显的减速?

肯定会放缓。它应该是可衡量的(或可估计的)。例如,如果您对自己的版本进行了分析,则可以看到在Character方法中花费了多少时间。

会有意义吗?很难预测!

  

第三,在我的代码中,我试图避免使用Hashmap的remove()函数。 ......我的逻辑是否正确?

是。但是,您可以再次通过基准测试和/或分析来验证这一点。

说完了所有这些,我的&gt;&gt;有根据的猜测&lt;&lt;是你的解决方案可能更适合小字符串,并且书籍解决方案肯定会对足够长的字符串更好地工作。它归结为两件事:

  • 本书解决方案预先分配了256个ints ... 1024字节的数组。分配空HashMap

  • 可能需要更长的时间
  • 自动装箱,地图查找和地图插入或更新的每字符成本可能远远高于图书解决方案中的等价成本。