[#5322] O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...>

I just did some benchmarks on push, pop, shift, and unshift

24 messages 2005/07/01
[#5338] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/02

On Fri, 1 Jul 2005, Eric Mahurin wrote:

[#5348] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/02

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5357] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/03

On Sat, 2 Jul 2005, Eric Mahurin wrote:

[#5359] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/03

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5361] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/03

On Sun, 3 Jul 2005, Eric Mahurin wrote:

[#5362] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/03

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5365] Re: O(1) performance for insertions/deletions at the front of an Array/String — Yukihiro Matsumoto <matz@...> 2005/07/04

Hi,

[#5367] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/04

--- Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#5368] Re: O(1) performance for insertions/deletions at the front of an Array/String — Yukihiro Matsumoto <matz@...> 2005/07/04

Hi,

[#5372] Re: O(1) performance for insertions/deletions at the front of an Array/String — Florian Gro<florgro@...> 2005/07/04

Yukihiro Matsumoto wrote:

[#5420] Sydney Developer Preview 1 released — Evan Webb <evanwebb@...>

Sydney, an experimental ruby interpreter, has been released!

15 messages 2005/07/11
[#5424] Re: [ANN] Sydney Developer Preview 1 released — Evan Webb <evanwebb@...> 2005/07/12

Thanks everyone for the feedback so far!

Re: Subversion

From: Ryan Davis <ryand-ruby@...>
Date: 2005-07-01 08:35:14 UTC
List: ruby-core #5315
On Jun 30, 2005, at 5:29 PM, Shugo Maeda wrote:

>> I wouldn't say subversion is better yet, just different.
>
> I think good points of Subversion are:
>
> : Not based on single file
>     CVS is based on single file, and doesn't support rename and  
> removal
>     well.  Subversion gives a revision to changes in all related  
> changes
>     per commit, so it's easy to track changes.
> : Security
>     Subversion is not perfect, but more secure than CVS.
>     We can use HTTPS and basic auth, so committers doesn't need
>     Unix accounts any more, and extra ports like pserver are not
>     necessary.
> : Easy to maintain
>     The complexity of loginfo of CVS is my headache. (I think it's  
> also
>     eban's headache)
>     post-commit of Subversion and `svnadmin dump' is easy to use.
>     `svnadmin dump' also supports incemental backup.
> : Trac
>     Trac (http://www.edgewall.com/trac/) is an issue tracking system.
>     Trac and Subversion are good friends. We can close a bug just to
>     write a ticket number in a commit log like:
>
>       fixed something. (closes #1234)
>
>     Trac has also a good repository browser for Subversion.
>     Please see http://dev.rubyonrails.com/ for example.

*nod*

These are all very good points, and with the exception of trac  
(although there is an open bug on this exception), all of these  
points are also supported by perforce. Perforce is free for open- 
source development and is used by larger groups like freebsd (http:// 
perforce.freebsd.org/). The clients are free to anyone and available  
on just about every version of every OS under the sun. It also has  
some other benefits:

+ Some commands/options just seem so much more straightforward (p4  
sync -n to see what you WOULD get if you sync'd, not svn -u st). At  
least they do to me.
+ Merging is much easier
+ Much more uniform use of revision identifiers across nearly all  
commands
+ Repository diffs are FAST (10x faster by my unscientific measure).
+ p4 opened -a (who has what open?) is _awesome_.
+ p4 describe $revision is _awesome_ (and much much faster than the  
equivalent in svn).
+ underneath it all, still rcs files, no binary DB to corrupt (there  
are binary DBs for metadata)
+ Proven scalability.
+ Much more mature and bug free.


In This Thread