[#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: [ANN] Sydney Developer Preview 1 released

From: Evan Webb <evanwebb@...>
Date: 2005-07-13 00:11:59 UTC
List: ruby-core #5437
Hello, 

see below.

On 7/12/05, nobu.nokada@softhome.net <nobu.nokada@softhome.net> wrote:
> Hi,
> 
> At Wed, 13 Jul 2005 03:10:17 +0900,
> Evan Webb wrote in [ruby-core:05430]:
> > > * macro _C in globals.h conflicted with one in ctype.h
> >
> > Hmmm. On which I dont have a _C macro under linux or freebsd.
> 
> I found it on cygwin.

Seems it appears other platforms too. I've change it to _CPATH (and
i'm going to change it to CPATH tonight as well, seems that _ macros
should be avoided).

> 
> > > * stringization by # needs ANSI C compiler
> >
> > Could you elaborate?
> 
>   #define _C(kls) rb_path2class0(#kls)
> 
> Making string literals from macro arguments prefixed by # is
> specified by ANSI standard, so older compilers may not support
> the feature.

Hm. Ok, I'll have to redo that to support other compilers. Any suggestions?

> 
> # And, // style comment is newer than it.

Yeah, thats just my bad habit (using // comments).

> 
> > > * using IDs as storages for temporary (and possibly long)
> > >   strings would not be a nice idea.  ID names never get freed
> > >   until the process dies.
> >
> > Hm. Where do you see me doing that? With the _S() macro? The _S()
> > macro just replaced global rb_intern()'d variables.
> 
> User defined % literals.
> 
>               case 1:
>                 lex_strterm = NEW_STRTERM(str_xquote, term, paren);
>                 pslval->id = rb_intern(tmpstr);
>                 return tXSTRING_BEG;

Well, my original thinking was that they they'd have to survive the
entire process  anyway since they were being used directly by a node.
But I see your point in that if the node were collected (perhaps
because remove_method was called), the rest of the node would be
removed but the % expansion string would survive. I should be able to
move the string elsewhere and make obj_free aware it may need to
remove the expansion string.

Hm. Ok, I checked out the code and perhaps what I'll do is add a VALUE
to the lval union and pass back rb_str_new2(tmpstr), then assign that
val to u2.value. The only problem there is that I then need to use
that to dispatch a method of the same name, so I end up having to call
rb_intern eventually anyway.

I'll have to think about this a bit more. Perhaps what I need is a
symbol that can be collected later. I'll think on it.

> 
> > > * there is a swap file of test/sydney/test_binding.rb
> >
> > A swap file? Like it takes up a bunch of memory?
> 
> Just a junk file, sydney-dr1/test/sydney/.test_binding.rb.swp

Yep, thanks. Found it and removed it.

> > > And it contains so many and large changes, can't you split it
> > > to some patches?
> >
> > Yes, I can split it up. The vast bulk of the changes were required to
> > get OS threads working properly, so all of that needs to be a single
> > thread. I could easily split off the other features (Backtrace / Frame
> > objects, other hooks, etc) into patchs.
> 
> As for Batktrace, I've been thinking about an iterator rather
> than a method returning an array.

iterator rather than the Backtrace class or rather than Backtrace#frames?

Having it the form of a fleshed out object is quite nice. I'm working
on GUI debugger that uses them to be able to display a full backtrace
that allows for jumping back in the code, etc. Having the the
filename, line, etc. makes all that easy.

Evan

> --
> Nobu Nakada
> 
>


In This Thread