您好，实际上我有形如K<-C（k1,k2,k1,k2,k3,k4,k1....)，V<-c(v1,v2,v2,v3,v3,v4,v1...)的两个vector，其中：
1. 两个vector的长度是相同的，且数据是按位置一一对应的，可以理解成有很多个(k,v)元组组成的向量;
2. K中的各个k值，和V中的各个v值，都有可能会重复出现，例如我给的例子中，k1,k2;v1,v2,v3就多次出现了；
3. 最终我要找到各个k都对应了哪些v，其中要把v中重复的去掉，然后放到一个list中；在list中用k值做命名，用v值组成的vector做内容。例如上面的例子会得到list(k1=c(v1,v2),k2=c(v2,v3),k3=c(v3),k4=c(v4)).
不知道我上面的解释清楚吗？

R里不用vectorize的函数的话性能是很不济的。感觉你的程序逻辑并不复杂，可以先用data.frame处理最后合并为list。或者你可以换一种思路，因为相对来说R处理data frame的包最多，而且有像data.table这样性能很好的包；list的话作为万能容器在性能上就自然要打折扣了

我不知道理解的对不对，如果不对请见谅：

我用以下两个随机数序列模拟k和v：
各50万个0~100之间的随机整数，中间肯定不少重复的。重要的事情说三遍：是各50万个，各50万个，各50万个；
首先，我会先按第一列（即k），再按第二列（即v）同时排序（其实这一步似乎是多于的，不过我个人喜欢数据整整齐齐）：
接下来这一步是最核心的，节约时间主要靠这个（应该是）用C编写的函数：
接下来基本就是收尾工作啦：
最后，看看时间花费多少，在我的i3CPU上的成绩：

3秒多时间，应该可以接受吧？

因为时间关系，没有仔细验证过各个步骤，如果有不对的地方请提出来，大家讨论。

最后总结一下，您原来的程序应该带有很浓的“C语言的口音”（这是我在r-blogger上看到的一句话，觉得挺酷），你一开始就把一个k元素和一个v元素看成是一个小向量，这不是真正的向量化。应该吧k，v看成一整个大向量（matrix是向量的一种）来通盘考虑。以上是我的一点点心得吧。

@cheetahfly 给你点120个赞！！！
我本人确实算半个C/Python程序员（之所以说半个是因为coding不是我的主业，但少不了要做demo），对数据处理还没有建立起向量化的思想。
除了本帖里面的问题，我程序里面还有一些被我逐行处理数据的地方，有了你这段程序做启发，我大概知道该怎么改了。
我最近1,2个月才开始接触R，今后少不得向您请教。

多交流，共同进步

昨天没有考虑周全，其实最后收尾阶段的那6行代码不是最简化的，应该可以一行代码，一个函数就搞定收尾
最终，应该三行代码可以全部搞定：
执行效率上未必有明显的进一步提升，但胜在代码较简化，逻辑更清晰，且较符合向量化的思想。

感谢！实测效率比原来的6行代码效率还有10倍以上的提升！
但也带来了个问题：split函数返回的list对象的长度是固定的！！！
比如你这里的lstResult <- split(xu[,2],xu[,1])
我原来的程序里面，对lstResult还有修改，就是将lstResult中的元素再增加一个属性。
例如原来的lstResult[[1]]$c1，我计算后又增加了lstResult[[1]]$c2
现在问题出来了：c1和c2的长度必须相同才行，否则报错！
但按照原来的方法没有问题。

看了你的描述，猜测问题出在c1和c2封装在一起的形式，matrix和dataframe要求c1和c2必须长度相同（会自动补齐，请检查清楚），list则不用。
一个可能的解决问题的方案是：
另外算出由另一个属性c2组成的list，我们暂时将它的名称定为lstResult2，注意，lstResult和lstResult2中的元素应该是一一对应的。然后再将两个list按c1、c2组装成一个子列表的形式组装在一起，比如：
你可以试试看。
多问一句，目前的耗时是多少？

哈哈，我也是用这种方法绕过这个坑的。
在我的服务器上处理50万条流量数据，用我最初逐条处理需要约4个小时，向量化后用for循环的方法需要240秒，用split方法不到3秒，见证奇迹的时刻啊！

再多说一句，python真是各种场景通吃，不用考虑优化，耗时稳定在2分钟以内。

我听着都很高兴

我刚看到题主加的问题说明，我感觉你是不是想复杂了？题主的要求应该就是split(v, k)吧？要去重复的话那就是lapply(split(v, k), unique)？还是我又理解错了。。。

感觉用reshape2也可以啊

确实更快
确实是学无止境
我在写第九楼的时候，基本上把思索的过程都写下来了，啰哩啰嗦的，思路也不是很清晰，在第12楼补充的时候，思路基本就定型了，其核心也是unique+split，不过，我是先unique，把数据中的“水分”挤出，再进行split，以为这样会更快，并且我可能有个偏见，对apply家族并不信任，认为他们是把显性循环隐形化了！
为什么会这样呢？
我尝试找了一下原因，结果发现：我去！差了两个数量级！
原因应该在这里了。
多谢了！

你需要用数据的思维你看你的问题

tapply(v, k, unique)

用logical operator， 和dplyr的package，可以把时间缩到1.5秒
library(dplyr)
k <- round(runif(500000, min = 0, max=1), digits = 2) * 100
v <- round(runif(500000, min = 0, max=1), digits = 2) * 100
tot <-
  data.frame(k, v) %>%
  arrange(k, v) %>%
  unique()
out <- with(tot, split(v, k))


   user  system elapsed
  1.556   0.000   1.554

您的代码对效率的提升，主要是来自于您是用sample做整数抽样，形成的数据是integer类型，而原来的模拟方法，形成的数据是double类型，两者处理起来速度差别很大。

好眼力。简答测试了一下，速度差在3.5倍左右

您这测试包好用啊！学到了。

抱歉，我过于乐观了。其实我处理的原始数据是50万条，归并后就只有10万条左右，最初处理大约15分钟，第一次向量化后约240秒，用split优化后3秒。

这个帖子持续热闹，让我又学到不少东西！

感谢“suimong”同学，他在18楼的发言一针见血：这个问题的本质是分割和去冗两个核心环节，对应split和unique函数就能解决；也感谢“ntsean”同学，他的tapply是目前调用函数最少的解决方案。

在本帖持续讨论的同时，另外一个帖子“求教：如何分割一个很大的字符矢量？”（https://bbs.pinggu.org/thread-4166951-1-1.html）也给了我很大启发，其中，“万人往LVR”同学的代码为我打开了另外一条思路；“suimong”同学的效率测试让我明白——在某些情况下split()也有可能成为不可小觑的性能瓶颈——在本例中就是这种状况。经大致分析，其原因很可能是由于split(x,f)中的f是专门针对factor类型，而把numeric型转化成factor型耗费巨量时间。（将k向量as.factor之后，split(v,k)的耗时基本上可以忽略不计了）

于是，我想能否专门针对numeric类型进行优化呢？按照“万人往LVR”同学的思路，我瞎写了一个split.num小函数，专门针对f参数是numeric vector时的分割：

复制代码

另外，根据楼主真实数据的特征，我将模拟k和v的方式稍微改变了一下，以达到“归并后有10万条左右”的效果。
我目前桌面的电脑CPU是i3，测试结果如下：

测试结束后，特意逐项比较了一下split和split.num的计算结果是否完全一致，答案是肯定的。

如果按照最初的k和v的模拟方法（归并后大概100条左右），split.num解决方案速度在0.3秒左右。无论如何，都在我的破电脑上实现了1秒以内完成了。

好了，我可以狗带了

......

好吧，其实还是有些不甘心。在整个过程中split.num()耗时的占比仍然太大，大家还有什么好的思路进一步优化吗？

经过一个周末的思考，我再把这个问题的解决方案优化了一步。

首先，各位同学别怪我在这个问题上的较真，因为“split”的问题是R语言数据处理中的一个普遍性问题，大神Hadley Wickham在其文章The Split-Apply-Combine Strategy for Data Analysis中就将Split-Apply-Combine的操作方法提升到了策略的高度，并因此有了plyr软件包。故而，将split的各种可能的瓶颈研究清晰，并提出针对性的优化方案，将终究会使大家未来的数据研究工作受益。

这次我的思路是从factor这一环节展开的。split()对factor参数与非factor参数的效率可谓天差地远：
由此，可知split环节的瓶颈其实是在as.factor环节。

而之前“ntsean”同学的发言让我无意中发现integer数据类型和double数据类型在as.factor环节也有着非常大的差别，比如：
至此，我推测数据类型是制约as.factor环节的一个重要因素，也是可以优化的一个重要方向。

我仔细观察了一下as.factor和factor两个函数，这两个函数都是用R语言编写的，并非用C语言。虽然我没有完全搞清楚其机理，但我猜测将integer和double的数据类型分开不同的程序处理仅仅是为了容错性上的考虑，而并非是技术性上的限制。

于是我将as.factor源程序中的一段抽取了出来，单独写了一个函数：
测试了一下，对double数据类型的操作是没有问题的，且效率提升了很多：
这下好了，我将在28楼的测试思路延续到新的含有factor.num()的解决方案上来，且我将每种方法均用30次测试，观测均值和中位数。第一种方法是“suimong”的lapply方法，第二种方法是“ntsean”的tapply方法，第三种是我用split.num()的解决办法（在本帖28楼有说明），第四种方法是本楼用factor.num()函数的方法。最后将结果检验了一下，没有问题。


OK，执行效率再进一步，在我的i3 CPU上基本0.6秒左右可以完成，不同的电脑上可能会更快。

通过这个例子，让我对R语言的优化有了很直观的感悟，其中一条，有些函数由于考虑容错性、兼容性的要求，往往代码会比较多，在一些比较极端的对优化要求很高的场合，如果针对具体数据的特点，去掉函数不必要的容错代码，有可能大幅提高执行效率。

不知我这一思路有没有错漏，多谢各位指正！

好了，以我的水平，已经在这个问题上发挥到极致了，现在我真的可以狗带了

真的是学习了。
system.time(lapply(split(v, factor.num(k)), unique))
   user  system elapsed
  0.048   0.004   0.057

把grouping 这部分用factor.num来运算，在我的laptop上可以提高到0.1秒以内。