Append an object to a list in R in amortized constant time O 1

Question

If I have some R list mylist  you can append an item obj to it like so   mylist  length mylist  1    lt - obj   But surely there is some more compact way   When I was new at R  I  tried writing lappend   like so   lappend  lt - function lst  obj        lst  length lst  1    lt - obj     return lst      but of course that doesn t work due to R s call-by-name semantics  lst is effectively copied upon call  so changes to lst are not visible outside the scope of lappend     I know you can do environment hacking in an R function to reach outside the scope of your function and mutate the calling environment  but that seems like a large hammer to write a simple append function   Can anyone suggest a more beautiful way of doing this  Bonus points if it works for both vectors and lists

User · Answer

For validation I ran the benchmark code provided by @Cron. There is one major difference (in addition to running faster on the newer i7 processor): the by_index now performs nearly as well as the list_:

Unit: milliseconds
              expr        min         lq       mean     median         uq
    env_with_list_ 167.882406 175.969269 185.966143 181.817187 185.933887
                c_ 485.524870 501.049836 516.781689 518.637468 537.355953
             list_   6.155772   6.258487   6.544207   6.269045   6.290925
          by_index   9.290577   9.630283   9.881103   9.672359  10.219533
           append_ 505.046634 543.319857 542.112303 551.001787 553.030110
 env_as_container_ 153.297375 154.880337 156.198009 156.068736 156.800135

For reference here is the benchmark code copied verbatim from @Cron's answer (just in case he later changes the contents):

n = 1e+4
library(microbenchmark)
### Using environment as a container
lPtrAppend <- function(lstptr, lab, obj) {lstptr[[deparse(substitute(lab))]] <- obj}
### Store list inside new environment
envAppendList <- function(lstptr, obj) {lstptr$list[[length(lstptr$list)+1]] <- obj}

microbenchmark(times = 5,
        env_with_list_ = {
            listptr <- new.env(parent=globalenv())
            listptr$list <- NULL
            for(i in 1:n) {envAppendList(listptr, i)}
            listptr$list
        },
        c_ = {
            a <- list(0)
            for(i in 1:n) {a = c(a, list(i))}
        },
        list_ = {
            a <- list(0)
            for(i in 1:n) {a <- list(a, list(i))}
        },
        by_index = {
            a <- list(0)
            for(i in 1:n) {a[length(a) + 1] <- i}
            a
        },
        append_ = {
            a <- list(0)
            for(i in 1:n) {a <- append(a, i)}
            a
        },
        env_as_container_ = {
            listptr <- new.env(parent=globalenv())
            for(i in 1:n) {lPtrAppend(listptr, i, i)}
            listptr
        }
)

User · Answer

I think what you want to do is actually pass by reference  pointer  to the function-- create a new environment  which are passed by reference to functions  with the list added to it   listptr new env parent globalenv    listptr list mylist   Then the function is modified as  lPtrAppend  lt - function lstptr  obj        lstptr list  length lstptr list  1    lt - obj     Now you are only modifying the existing list  not creating a new one

User · Answer

This is a straightforward way to add items to an R List     create an empty list  small list   list      now put some objects in it  small list k1    v1  small list k2    v2  small list k3   1 10    retrieve them the same way  small list k1   returns  v1      index  notation works as well  small list  k2     Or programmatically   kx   paste LETTERS 1 5   1 5  sep     vx   runif 5  lx   list   cn   1  for  itm in kx    lx itm    vx cn   cn   cn   1    print length lx     returns 5

User · Answer

try this function lappend  lappend  lt - function  lst          lst  lt - c lst  list         return lst      and other suggestions from this page Add named vector to a list  Bye

User · Answer

This is a very interesting question and I hope my thought below could contribute an way of solution to it  This method do give a flat list without indexing  but it does have list and unlist to avoid the nesting structures  I m not sure about the speed since I don t know how to benchmark it   a list lt -list   for i in 1 3     a list lt -list unlist list unlist a list recursive   FALSE  list rnorm 2    recursive   FALSE     a list    1     1    1    1  -0 8098202  1 1035517    1    2    1  0 6804520 0 4664394    1    3    1  0 15592354 0 07424637

User · Answer

The OP  in the April 2012 updated revision of the question  is interested in knowing if there s a way to add to a list in amortized constant time  such as can be done  for example  with a C   vector lt  gt  container  The best answer s   here so far only show the relative execution times for various solutions given a fixed-size problem  but do not address any of the various solutions  algorithmic efficiency directly  Comments below many of the answers discuss the algorithmic efficiency of some of the solutions  but in every case to date  as of April 2015  they come to the wrong conclusion   Algorithmic efficiency captures the growth characteristics  either in time  execution time  or space  amount of memory consumed  as a problem size grows  Running a performance test for various solutions given a fixed-size problem does not address the various solutions  growth rate  The OP is interested in knowing if there is a way to append objects to an R list in  amortized constant time   What does that mean  To explain  first let me describe  constant time     Constant or O 1  growth   If the time required to perform a given task remains the same as the size of the problem doubles  then we say the algorithm exhibits constant time growth  or stated in  Big O  notation  exhibits O 1  time growth  When the OP says  amortized  constant time  he simply means  in the long run     i e   if performing a single operation occasionally takes much longer than normal  e g  if a preallocated buffer is exhausted and occasionally requires resizing to a larger buffer size   as long as the long-term average performance is constant time  we ll still call it O 1    For comparison  I will also describe  linear time  and  quadratic time   Linear or O n  growth   If the time required to perform a given task doubles as the size of the problem doubles  then we say the algorithm exhibits linear time  or O n  growth  Quadratic or O n2  growth   If the time required to perform a given task increases by the square of the problem size  them we say the algorithm exhibits quadratic time  or O n2  growth    There are many other efficiency classes of algorithms  I defer to the Wikipedia article for further discussion   I thank  CronAcronis for his answer  as I am new to R and it was nice to have a fully-constructed block of code for doing a performance analysis of the various solutions presented on this page  I am borrowing his code for my analysis  which I duplicate  wrapped in a function  below   library microbenchmark      Using environment as a container lPtrAppend  lt - function lstptr  lab  obj   lstptr  deparse substitute lab      lt - obj      Store list inside new environment envAppendList  lt - function lstptr  obj   lstptr list  length lstptr list  1    lt - obj   runBenchmark  lt - function n        microbenchmark times   5            env with list                  listptr  lt - new env parent globalenv                listptr list  lt - NULL             for i in 1 n   envAppendList listptr  i               listptr list                    c                  a  lt - list 0              for i in 1 n   a   c a  list i                       list                  a  lt - list 0              for i in 1 n   a  lt - list a  list i                       by index                 a  lt - list 0              for i in 1 n   a length a    1   lt - i              a                    append                   a  lt - list 0                  for i in 1 n   a  lt - append a  i                a                    env as container                  listptr  lt - new env parent globalenv                for i in 1 n   lPtrAppend listptr  i  i                listptr                        The results posted by  CronAcronis definitely seem to suggest that the a  lt - list a  list i   method is fastest  at least for a problem size of 10000  but the results for a single problem size do not address the growth of the solution  For that  we need to run a minimum of two profiling tests  with differing problem sizes    gt  runBenchmark 2e 3  Unit  microseconds               expr       min        lq      mean    median       uq       max neval     env with list   8712 146  9138 250 10185 533 10257 678 10761 33 12058 264     5                 c  13407 657 13413 739 13620 976 13605 696 13790 05 13887 738     5              list    854 110   913 407  1064 463   914 167  1301 50  1339 132     5           by index 11656 866 11705 140 12182 104 11997 446 12741 70 12809 363     5            append  15986 712 16817 635 17409 391 17458 502 17480 55 19303 560     5  env as container  19777 559 20401 702 20589 856 20606 961 20939 56 21223 502     5  gt  runBenchmark 2e 4  Unit  milliseconds               expr         min         lq        mean    median          uq         max neval     env with list   534 955014  550 57150  550 329366  553 5288  553 955246  558 636313     5                 c  1448 014870 1536 78905 1527 104276 1545 6449 1546 462877 1558 609706     5              list     8 746356    8 79615    9 162577    8 8315    9 601226    9 837655     5           by index  953 989076 1038 47864 1037 859367 1064 3942 1065 291678 1067 143200     5            append  1634 151839 1682 94746 1681 948374 1689 7598 1696 198890 1706 683874     5  env as container   204 134468  205 35348  208 011525  206 4490  208 279580  215 841129     5  gt     First of all  a word about the min lq mean median uq max values  Since we are performing the exact same task for each of 5 runs  in an ideal world  we could expect that it would take exactly the same amount of time for each run  But the first run is normally biased toward longer times due to the fact that the code we are testing is not yet loaded into the CPU s cache  Following the first run  we would expect the times to be fairly consistent  but occasionally our code may be evicted from the cache due to timer tick interrupts or other hardware interrupts that are unrelated to the code we are testing  By testing the code snippets 5 times  we are allowing the code to be loaded into the cache during the first run and then giving each snippet 4 chances to run to completion without interference from outside events  For this reason  and because we are really running the exact same code under the exact same input conditions each time  we will consider only the  min  times to be sufficient for the best comparison between the various code options   Note that I chose to first run with a problem size of 2000 and then 20000  so my problem size increased by a factor of 10 from the first run to the second   Performance of the list solution  O 1   constant time   Let s first look at the growth of the list solution  since we can tell right away that it s the fastest solution in both profiling runs  In the first run  it took 854 microseconds  0 854 milliseconds  to perform 2000  append  tasks  In the second run  it took 8 746 milliseconds to perform 20000  append  tasks  A na  ve observer would say   Ah  the list solution exhibits O n  growth  since as the problem size grew by a factor of ten  so did the time required to execute the test   The problem with that analysis is that what the OP wants is the growth rate of a single object insertion  not the growth rate of the overall problem  Knowing that  it s clear then that the list solution provides exactly what the OP wants  a method of appending objects to a list in O 1  time   Performance of the other solutions  None of the other solutions come even close to the speed of the list solution  but it is informative to examine them anyway   Most of the other solutions appear to be O n  in performance  For example  the by index solution  a very popular solution based on the frequency with which I find it in other SO posts  took 11 6 milliseconds to append 2000 objects  and 953 milliseconds to append ten times that many objects  The overall problem s time grew by a factor of 100  so a na  ve observer might say  Ah  the by index solution exhibits O n2  growth  since as the problem size grew by a factor of ten  the time required to execute the test grew by a factor of 100   As before  this analysis is flawed  since the OP is interested in the growth of a single object insertion  If we divide the overall time growth by the problem s size growth  we find that the time growth of appending objects increased by a factor of only 10  not a factor of 100  which matches the growth of the problem size  so the by index solution is O n   There are no solutions listed which exhibit O n2  growth for appending a single object

User · Answer

If it s a list of string  just use the c   function    R gt  LL  lt - list a  tom   b  dick   R gt  c LL  c  harry    a  1   tom    b  1   dick    c  1   harry   R gt  class LL   1   list  R gt     That works on vectors too  so do I get the bonus points   Edit  2015-Feb-01   This post is coming up on its fifth birthday   Some kind readers keep repeating any shortcomings with it  so by all means also see some of the comments below  One suggestion for list types   newlist  lt - list oldlist  list someobj     In general  R types can make it hard to have one and just one idiom for all types and uses

User · Answer

If you pass in the list variable as a quoted string  you can reach it from within the function like   push  lt - function l  x      assign l  append eval as name l    x   envir parent frame        so    gt  a  lt - list 1 2   gt  a   1    1  1    2    1  2   gt  push  a   3   gt  a   1    1  1    2    1  2    3    1  3   gt     or for extra credit    gt  v  lt - vector    gt  push  v   1   gt  v  1  1  gt  push  v   2   gt  v  1  1 2  gt

User · Answer

There is also list append from the rlist  link to the documentation   require rlist  LL  lt - list a  Tom   b  Dick   list append LL d  Pam  f c  Joe   Ann      It s very simple and efficient

User · Answer

mylist lt -list 1 2 3  mylist lt -c mylist list 5    So we can easily append the element object using the above code

User · Answer

Not sure why you don t think your first method won t work   You have a bug in the lappend function  length list  should be length lst    This works fine and returns a list with the appended obj

User · Answer

In the Lisp we did it this way    gt  l  lt - c 1   gt  l  lt - c 2  l   gt  l  lt - c 3  l   gt  l  lt - rev l   gt  l  1  1 2 3   though it was  cons   not just  c   If you need to start with an empy list  use l  lt - NULL

User · Answer

gt  LL lt -list 1 4    gt  LL    1    1  1 2 3 4   gt  LL lt -list c unlist LL  5 9     gt  LL    1     1  1 2 3 4 5 6 7 8 9

User · Answer

You want something like this maybe    gt  push  lt - function l  x       lst  lt - get l  parent frame       lst length lst  1   lt - x    assign l  lst  envir parent frame        gt  a  lt - list 1 2   gt  push  a   6   gt  a   1    1  1    2    1  2    3    1  6   It s not a very polite function  assigning to parent frame   is kind of rude  but IIUYC it s what you re asking for

User · Answer

In the other answers  only the list approach results in O 1  appends  but it results in a deeply nested list structure  and not a plain single list  I have used the below datastructures  they supports O 1   amortized  appends  and allow the result to be converted back to a plain list    expandingList  lt - function capacity   10        buffer  lt - vector  list   capacity      length  lt - 0      methods  lt - list        methods double size  lt - function             buffer  lt  lt - c buffer  vector  list   capacity           capacity  lt  lt - capacity   2            methods add  lt - function val            if length    capacity                methods double size                      length  lt  lt - length   1         buffer  length    lt  lt - val            methods as list  lt - function             b  lt - buffer 0 length          return b             methods     and  linkedList  lt - function         head  lt - list 0      length  lt - 0      methods  lt - list        methods add  lt - function val            length  lt  lt - length   1         head  lt  lt - list head  val             methods as list  lt - function             b  lt - vector  list   length          h  lt - head         for i in length 1                b  i    lt - head  2               head  lt - head  1                     return b            methods     Use them as follows    gt  l  lt - expandingList    gt  l add  hello    gt  l add  world    gt  l add 101   gt  l as list     1    1   hello     2    1   world     3    1  101   These solutions could be expanded into full objects that support al list-related operations by themselves  but that will remain as an exercise for the reader    Another variant for a named list   namedExpandingList  lt - function capacity   10        buffer  lt - vector  list   capacity      names  lt - character capacity      length  lt - 0      methods  lt - list        methods double size  lt - function             buffer  lt  lt - c buffer  vector  list   capacity           names  lt  lt - c names  character capacity           capacity  lt  lt - capacity   2            methods add  lt - function name  val            if length    capacity                methods double size                      length  lt  lt - length   1         buffer  length    lt  lt - val         names length   lt  lt - name            methods as list  lt - function             b  lt - buffer 0 length          names b   lt - names 0 length          return b             methods     Benchmarks  Performance comparison using  phonetagger s code  which is based on  Cron Arconis  code   I have also added a better env as container and changed the env as container  a bit  The original env as container  was broken and doesn t actually store all the numbers   library microbenchmark  lPtrAppend  lt - function lstptr  lab  obj   lstptr  deparse lab     lt - obj      Store list inside new environment envAppendList  lt - function lstptr  obj   lstptr list  length lstptr list  1    lt - obj   env2list  lt - function env  len        l  lt - vector  list   len      for  i in 1 len            l  i    lt - env  as character i              l   envl2list  lt - function env  len        l  lt - vector  list   len      for  i in 1 len            l  i    lt - env  paste as character i    L   sep                 l   runBenchmark  lt - function n        microbenchmark times   5            env with list                  listptr  lt - new env parent globalenv                listptr list  lt - NULL             for i in 1 n   envAppendList listptr  i               listptr list                    c                  a  lt - list 0              for i in 1 n   a   c a  list i                       list                  a  lt - list 0              for i in 1 n   a  lt - list a  list i                       by index                 a  lt - list 0              for i in 1 n   a length a    1   lt - i              a                    append                   a  lt - list 0                  for i in 1 n   a  lt - append a  i                a                    env as container                  listptr  lt - new env hash TRUE  parent globalenv                for i in 1 n   lPtrAppend listptr  i  i                envl2list listptr  n                     better env as container                 env  lt - new env hash TRUE  parent globalenv                for i in 1 n  env  as character i     lt - i             env2list env  n                     linkedList                 a  lt - linkedList               for i in 1 n    a add i                a as list                      inlineLinkedList                 a  lt - list               for i in 1 n    a  lt - list a  i                b  lt - vector  list   n              head  lt - a             for i in n 1                    b  i    lt - head  2                   head  lt - head  1                                                    expandingList                 a  lt - expandingList               for i in 1 n    a add i                a as list                      inlineExpandingList                 l  lt - vector  list   10              cap  lt - 10             len  lt - 0             for i in 1 n                    if len    cap                        l  lt - c l  vector  list   cap                       cap  lt - cap 2                                   len  lt - len   1                 l  len    lt - i                           l 1 len                       We need to repeatedly add an element to a list  With normal list concatenation   or element setting this would lead to a large number of memory copies and a   quadratic runtime  To prevent that  this function implements a bare bones   expanding array  in which list appends are  amortized  constant time      expandingList  lt - function capacity   10            buffer  lt - vector  list   capacity          length  lt - 0          methods  lt - list            methods double size  lt - function                 buffer  lt  lt - c buffer  vector  list   capacity               capacity  lt  lt - capacity   2                    methods add  lt - function val                if length    capacity                    methods double size                              length  lt  lt - length   1             buffer  length    lt  lt - val                    methods as list  lt - function                 b  lt - buffer 0 length              return b                     methods            linkedList  lt - function             head  lt - list 0          length  lt - 0          methods  lt - list            methods add  lt - function val                length  lt  lt - length   1             head  lt  lt - list head  val                     methods as list  lt - function                 b  lt - vector  list   length              h  lt - head             for i in length 1                    b  i    lt - head  2                   head  lt - head  1                             return b                     methods          We need to repeatedly add an element to a list  With normal list concatenation   or element setting this would lead to a large number of memory copies and a   quadratic runtime  To prevent that  this function implements a bare bones   expanding array  in which list appends are  amortized  constant time      namedExpandingList  lt - function capacity   10            buffer  lt - vector  list   capacity          names  lt - character capacity          length  lt - 0          methods  lt - list            methods double size  lt - function                 buffer  lt  lt - c buffer  vector  list   capacity               names  lt  lt - c names  character capacity               capacity  lt  lt - capacity   2                    methods add  lt - function name  val                if length    capacity                    methods double size                              length  lt  lt - length   1             buffer  length    lt  lt - val             names length   lt  lt - name                    methods as list  lt - function                 b  lt - buffer 0 length              names b   lt - names 0 length              return b                     methods         result    gt  runBenchmark 1000  Unit  microseconds                     expr       min        lq      mean    median        uq       max neval           env with list   3128 291  3161 675  4466 726  3361 837  3362 885  9318 943     5                       c   3308 130  3465 830  6687 985  8578 913  8627 802  9459 252     5                    list    329 508   343 615   389 724   370 504   449 494   455 499     5                 by index  3076 679  3256 588  5480 571  3395 919  8209 738  9463 931     5                  append   4292 321  4562 184  7911 882 10156 957 10202 773 10345 177     5        env as container  24471 511 24795 849 25541 103 25486 362 26440 591 26511 200     5  better env as container  7671 338  7986 597  8118 163  8153 726  8335 659  8443 493     5               linkedList  1700 754  1755 439  1829 442  1804 746  1898 752  1987 518     5         inlineLinkedList  1109 764  1115 352  1163 751  1115 631  1206 843  1271 166     5            expandingList  1422 440  1439 970  1486 288  1519 728  1524 268  1525 036     5      inlineExpandingList   942 916   973 366  1002 461  1012 197  1017 784  1066 044     5  gt  runBenchmark 10000  Unit  milliseconds                     expr        min         lq       mean     median         uq        max neval           env with list  357 760419 360 277117 433 810432 411 144799 479 090688 560 779139     5                       c  685 477809 734 055635 761 689936 745 957553 778 330873 864 627811     5                    list    3 257356   3 454166   3 505653   3 524216   3 551454   3 741071     5                 by index 445 977967 454 321797 515 453906 483 313516 560 374763 633 281485     5                  append  610 777866 629 547539 681 145751 640 936898 760 570326 763 896124     5        env as container  281 025606 290 028380 303 885130 308 594676 314 972570 324 804419     5  better env as container  83 944855  86 927458  90 098644  91 335853  92 459026  95 826030     5               linkedList  19 612576  24 032285  24 229808  25 461429  25 819151  26 223597     5         inlineLinkedList  11 126970  11 768524  12 216284  12 063529  12 392199  13 730200     5            expandingList  14 735483  15 854536  15 764204  16 073485  16 075789  16 081726     5      inlineExpandingList  10 618393  11 179351  13 275107  12 391780  14 747914  17 438096     5  gt  runBenchmark 20000  Unit  milliseconds                     expr         min          lq       mean      median          uq         max neval           env with list  1723 899913 1915 003237 1921 23955 1938 734718 1951 649113 2076 910767     5                       c  2759 769353 2768 992334 2810 40023 2820 129738 2832 350269 2870 759474     5                    list     6 112919    6 399964    6 63974    6 453252    6 910916    7 321647     5                 by index 2163 585192 2194 892470 2292 61011 2209 889015 2436 620081 2458 063801     5                  append  2832 504964 2872 559609 2983 17666 2992 634568 3004 625953 3213 558197     5        env as container   573 386166  588 448990  602 48829  597 645221  610 048314  642 912752     5  better env as container  154 180531  175 254307  180 26689  177 027204  188 642219  206 230191     5               linkedList   38 401105   47 514506   46 61419   47 525192   48 677209   50 952958     5         inlineLinkedList   25 172429   26 326681   32 33312   34 403442   34 469930   41 293126     5            expandingList   30 776072   30 970438   34 45491   31 752790   38 062728   40 712542     5      inlineExpandingList   21 309278   22 709159   24 64656   24 290694   25 764816   29 158849     5   I have added linkedList and expandingList and an inlined version of both  The inlinedLinkedList is basically a copy of list   but it also converts the nested structure back into a plain list  Beyond that the difference between the inlined and non-inlined versions is due to the overhead of the function calls   All variants of expandingList and linkedList show O 1  append performance  with the benchmark time scaling linearly with the number of items appended  linkedList is slower than expandingList  and the function call overhead is also visible  So if you really need all the speed you can get  and want to stick to R code   use an inlined version of expandingList   I ve also had a look at the C implementation of R  and both approaches should be O 1  append for any size up until you run out of memory   I have also changed env as container   the original version would store every item under index  i   overwriting the previously appended item  The better env as container I have added is very similar to env as container  but without the deparse stuff  Both exhibit O 1  performance  but they have an overhead that is quite a bit larger than the linked expanding lists   Memory overhead  In the C R implementation there is an overhead of 4 words and 2 ints per allocated object  The linkedList approach allocates one list of length two per append  for a total of  4 8 4 4 2 8   56 bytes per appended item on 64-bit computers  excluding memory allocation overhead  so probably closer to 64 bytes   The expandingList approach uses one word per appended item  plus a copy when doubling the vector length  so a total memory usage of up to 16 bytes per item  Since the memory is all in one or two objects the per-object overhead is insignificant  I haven t looked deeply into the env memory usage  but I think it will be closer to linkedList

User · Answer

in fact there is a subtelty with the c   function  If you do   x  lt - list   x  lt - c x 2  x   c x  foo     you will obtain as expected     1    1     2    1   foo    but if you add a matrix with x  lt - c x  matrix 5 2 2   your list will have another 4 elements of value 5   You would better do   x  lt - c x  list matrix 5 2 2     It works for any other object and you will obtain as expected     1    1     2    1   foo     3          1    2   1      5    5  2      5    5   Finally  your function becomes   push  lt - function l       c l  list         and it works for any type of object  You can be smarter and do   push back  lt - function l       c l  list       push front  lt - function l       c list       l

User · Answer

I have made a small comparison of methods mentioned here   n   1e 4 library microbenchmark      Using environment as a container lPtrAppend  lt - function lstptr  lab  obj   lstptr  deparse substitute lab      lt - obj      Store list inside new environment envAppendList  lt - function lstptr  obj   lstptr list  length lstptr list  1    lt - obj    microbenchmark times   5            env with list                  listptr  lt - new env parent globalenv                listptr list  lt - NULL             for i in 1 n   envAppendList listptr  i               listptr list                    c                  a  lt - list 0              for i in 1 n   a   c a  list i                       list                  a  lt - list 0              for i in 1 n   a  lt - list a  list i                       by index                 a  lt - list 0              for i in 1 n   a length a    1   lt - i              a                    append                   a  lt - list 0                  for i in 1 n   a  lt - append a  i                a                    env as container                  listptr  lt - new env parent globalenv                for i in 1 n   lPtrAppend listptr  i  i                listptr                  Results   Unit  milliseconds               expr       min        lq       mean    median        uq       max neval cld     env with list   188 9023  198 7560  224 57632  223 2520  229 3854  282 5859     5  a                  c  1275 3424 1869 1064 2022 20984 2191 7745 2283 1199 2491 7060     5   b              list    17 4916   18 1142   22 56752   19 8546   20 8191   36 5581     5  a            by index  445 2970  479 9670  540 20398  576 9037  591 2366  607 6156     5  a             append  1140 8975 1316 3031 1794 10472 1620 1212 1855 3602 3037 8416     5   b  env as container   355 9655  360 1738  399 69186  376 8588  391 7945  513 6667     5  a

[r] Append an object to a list in R in amortized constant time, O(1)?

Examples related to r

Examples related to performance

Examples related to list

Examples related to append

Examples related to big-o