Ernie Rael wrote:

> This doesn't produce an error. Should it?
> 
>     const c1 = 3
>     unlockvar c1
> 
> Of course, there is an error on an attempt to modify c1.

It's better to give an error when trying to unlock.  I'll make a patch
for that.

> I was wondering about const optimizations; figured now's not the time to 
> mention it. Then saw that "len('string')" would be done at compile time. 
> So here goes.
> 
> Is a list a cheap kind of a "C" struct. Define the struct like
> 
>     const field1 = 0
>     const field2 = 1
>     const field3 = 2
> 
> and use these consts as list indexes. The struct is adjusted by changing 
> the const's.

That works, but there currently is no optimization for using a const
variable in a compiled function, like there is for a number.  Maybe this
can be implemented later.  You can see what happens using the
:disassemble command.

> Using a dict gives the cleanest looking code, and I'd guess the worst 
> performance.

Dictionary access has a bit of overhead, since a hash is computed to
look up items.  But the implementation has been tweaked to be fast (it's
very similar to how Python does this, and they have spent time on
optimizing the dictionary implementation).  In the end you can only know
by trying and measuring the performance.

> Since I haven't looked at the vim9 VM, it may be that PUSHNR/LISTINDEX 
> and LOADSCRIPT/LISTINDEX and MEMBER-'foo'/USEDICT are comparable (not 
> talking tight loop) and it's purely psychological and I shouldn't use 
> disassemble. But the constant value is typically available at compile 
> time for LISTINDEX.

A rough estimation is that every "simple" instruction takes some amount
of time.  If something can be done at compile time and it's executed
often, then it does get a lot faster.

> Something major I can't answer: are lists arrays or linked? That can 
> change the balance towards dict.

Yes :-).  Lists are linked, but sequential access can be fast.  Again,
you should try it out and measure perfornamce.  Moderns CPUs can execute
instructions very fast and caching often kicks in, making performance
largely unpredictable.

-- 
There is no right or wrong, there is only your personal opinion.
                 (Bram Moolenaar)

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///                                                                      \\\
\\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/20220404130900.A37BA1C05DA%40moolenaar.net.

Raspunde prin e-mail lui