r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

[unknown: 5]
7-Feb-2009
[10681]
The remove is better.
BrianH
7-Feb-2009
[10682x2]
They are within variance of each other in this case. Interchangeable. 
After multiple runs, both get faster times than the other.
Which is weird, because REMOVE does more work than CLEAR, what with 
the refinement checking.
[unknown: 5]
7-Feb-2009
[10684]
I think it is the amount of movement via the index that is time consuming 
for the other method.
BrianH
7-Feb-2009
[10685]
That would be the same with both. Well, remove is easier to undeerstand 
than clear, so it's a good choice.
[unknown: 5]
7-Feb-2009
[10686]
Clear might have a lot of underlying code for ports use as well which 
may be the reason why remove is better.
BrianH
7-Feb-2009
[10687x2]
Nah, both are actions so there is no type-specific overhead that 
affects use with other types.
And I didn't fine remove to be better consistently. Clear won half 
the time with the same code.
[unknown: 5]
7-Feb-2009
[10689x2]
I don't know.  That is why we profile.  ;-)
The remove is more CLEAR to understand.  Pun intended.
BrianH
7-Feb-2009
[10691x2]
I ran a dozen profiles of each, and they were 50/50 on which was 
faster. That is well within the profiler variance.
I submitted a tweak to dp that improves the accuracy, but the profiler 
is too inconsistent to time differences this small well enough.
[unknown: 5]
7-Feb-2009
[10693]
Well you definately want to make sure your profiler works.
BrianH
7-Feb-2009
[10694x2]
It works for big differences well enough (based on my testing).
For instance, that /into proposal was based on huge differences picked 
up by the profiler. If implemented it could eventually lead to user-visible 
reductions in overhead. That's a big deal.
[unknown: 5]
7-Feb-2009
[10696]
When profiling traversal operations, I have experienced skewed results.
BrianH
7-Feb-2009
[10697]
Interesting. Examples?
[unknown: 5]
7-Feb-2009
[10698x2]
Well, my get-block function is an example.  I used it on a series 
of block data and get different results that don't seem to jive with 
my expectations.
Some more complex reads actually resulted in better performance then 
less complex reads.
BrianH
7-Feb-2009
[10700]
Are you talking about file access?
[unknown: 5]
7-Feb-2009
[10701x2]
I had done a test where I read a small 5000 record file and compared 
to a 100000 record file and the 100000 record file proviled better 
performance than the smaller one.
After the file read.
BrianH
7-Feb-2009
[10703]
Sounds like cache is a factor here.
[unknown: 5]
7-Feb-2009
[10704x3]
http://www.tretbase.com/forum/viewtopic.php?f=8&t=30#p131
That function.
Cache is definately a factor in those type of operations.
BrianH
7-Feb-2009
[10707]
Looks like parse could help with the speed, but it might be harder 
to get it right.
[unknown: 5]
7-Feb-2009
[10708x2]
I started to go that route but started getting bad performance so 
I went this route utilizing find.
It was most likely an implementation detail as find I assume uses 
parse.
BrianH
7-Feb-2009
[10710]
Nope. FIND is faster than PARSE, but PARSE is faster than FIND with 
WHILE.
[unknown: 5]
7-Feb-2009
[10711]
And while is slower than until and foreach.  It gets complicated.
BrianH
7-Feb-2009
[10712x4]
The trick is that it is harder to write and optimize parse code, 
so it can get really slow without you understanding why. The downside.
It gets complicated.

 It gets more complicated with R3, since R3 has made most of the previously 
 mezzanine loop functions native. This means that FORALL and FORSKIP 
 are faster than FOREACH in R3, while they are much slower in R2.
LOOP is still the fastest though :)
Paul, it looks like that ANY+ function has potential, with some tweaks.
[unknown: 5]
7-Feb-2009
[10716x2]
Yeah, that is my hope that some of those spark some interests.  Feel 
free to add comments on the site as well or updates to the functions 
that you feel could be more beneficial.  The goal of that thread 
was really to open the discussion of mezzanines and how to improve 
them.
ALTME is not the best medium for that type of  effort.  The forum 
remains with some clean code and examples.
BrianH
7-Feb-2009
[10718]
Don't forget to bring up the most general of your library functions 
that would get the most use in the Idioms group.
[unknown: 5]
7-Feb-2009
[10719x2]
My favorite one there is the evals function.
Your talking about on RebDev?
BrianH
7-Feb-2009
[10721]
Yeah. This kind of discussion is the whole point of R3 chat.
[unknown: 5]
7-Feb-2009
[10722x2]
RebDev is not user-friendly enough for me yet.
I know how to move in it but it is just a pain compared to alternate 
methods.
BrianH
7-Feb-2009
[10724x3]
I was wondering why you weren't invollving yourself in the conversation. 
Functionally it is much better than AltME, though the UI sucks.
Still some missing features though.
In theory the new logic! for R3 will solve the same problem that 
EVALS solves, but logic! flags doesn't work too well yet.
[unknown: 5]
7-Feb-2009
[10727]
Really, that is it.  I think there would be much more involvement 
if the UI was much better.  I think the problem is that Carl is still 
in honeymoon stage with RebDev and doesn't yet understand how much 
work is still really needed to get it embraced.  At this point I 
think ALTME is far better medium than RebDev.
BrianH
7-Feb-2009
[10728]
AltME is horrible for useful, focused discussions. No threading, 
no subtopics, no moderation. R3 chat is already better for that.
[unknown: 5]
7-Feb-2009
[10729x2]
Evals could be improved dramatically to be a very cool function.
Well in a sense ALTME has as much threading as RebDev by the means 
of groups.