[#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: Austin Ziegler <halostatue@...>
Date: 2005-07-01 15:49:46 UTC
List: ruby-core #5324
On 7/1/05, Ryan Davis <ryand-ruby@zenspider.com> wrote:
> On Jun 30, 2005, at 5:29 PM, Shugo Maeda wrote:
>>> I wouldn't say subversion is better yet, just different.
> *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.

Agreed -- I'm using P4 at work and finding it generally pretty nice.
I like the changeset mentality (changes are atomic). There are some
downsides to p4, though, mostly related to clientspecs.

The use of clientspecs is annoying. Since state is managed on the
server, you only get a synced file when the server thinks you've
synced it. This can result in a proliferation of clientspecs under
some circumstances. This may be a product of the way that we have to
work at work, but I have at least a dozen clientspecs that I use
regularly. (In fact, I've written a script to make those clientspecs
work.)

On the flip side, the use of a Win32 clientspec could eliminate
those things from visibility that don't build on Win32, for example.
Branches are more clearly defined, too.

We successfully use P4 on every platform we support *except* iSeries
(AS/400) and NetWare.

I believe that p4web is how you would manage a P4 repository from
the web. Another downside is that I don't know how to manage
anonymous access to a repository, which would be nice. (I'd love
to get your mainline version of ZenWeb, Ryan. ;)

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca


In This Thread