Hi, Alex. > >I haven't tried the code, or analyzed it in detail. But indeed I would >also expect that the time should increase linearly. > Right. I have played with the code a little (and used bench) and it seems to point to IO being the issue.
Here is the timing info : (bench (main 10)) 0.009 sec : (bench (main 100)) 0.100 sec : (bench (main 1000)) 0.663 sec : (bench (main 10000)) 6.540 sec When I replace (prinl (make-nametring-code)) with the same work, but throwing it away without IO (prin '.)(setq tmp '(make-namestring-code)) Then it becomes almost instantaneous : (bench (altmain 10)) 0.000 sec : (bench (altmain 100)) 0.000 sec : (bench (altmain 1000)) 0.000 sec : (bench (altmain 10000)) 0.001 sec I am less surprised by this than how Matz and the Ruby-guys got their code to be constant. As I mentioned earlier, this is purely an observation, not a criticism. I am enjoying plisp very much. > >The amount of data (= length of the lists) is the same in each test, >right? Because, if the lists were longer, accessing them with 'get' >would cause an exponential increase. > Yup. They are constant. One slurp for each file into lists. Then random access of the lists n-times. >You might consider some measurements to find out what causes this >behavior. Especially, take a look at the profiling library in >"@lib/prof.l". Or simply use 'bench'. > I had a quick look at prof.l but it is not clear to me how to use (profile). Can you give a quick example? Many thanks. .. mark. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
