Patch 9.0.1426

[Bram Moolenaar]

Patch 9.0.1426
Problem:Indent wrong after "export namespace" in C++.
Solution:   Skip over "inline" and "export" in any order. (Virginia Senioria,
closes #12134, closes #12133)
Files:  src/cindent.c, src/testdir/test_cindent.vim


*** ../vim-9.0.1425/src/cindent.c   2023-01-22 21:14:32.613863616 +
--- src/cindent.c   2023-03-24 19:24:04.260005272 +
***
*** 769,775 
  
  s = cin_skipcomment(s);
  
! if (STRNCMP(s, "inline", 6) == 0 && (s[6] == NUL || !vim_iswordc(s[6])))
s = cin_skipcomment(skipwhite(s + 6));
  
  if (STRNCMP(s, "namespace", 9) == 0 && (s[9] == NUL || 
!vim_iswordc(s[9])))
--- 769,777 
  
  s = cin_skipcomment(s);
  
! // skip over "inline" and "export" in any order
! while ((STRNCMP(s, "inline", 6) == 0 || STRNCMP(s, "export", 6) == 0)
!   && (s[6] == NUL || !vim_iswordc(s[6])))
s = cin_skipcomment(skipwhite(s + 6));
  
  if (STRNCMP(s, "namespace", 9) == 0 && (s[9] == NUL || 
!vim_iswordc(s[9])))
*** ../vim-9.0.1425/src/testdir/test_cindent.vim2022-05-21 
21:24:02.0 +0100
--- src/testdir/test_cindent.vim2023-03-24 19:21:11.407760413 +
***
*** 4406,4411 
--- 4406,4423 
inline/* test */namespace {
  11;
}
+   export namespace {
+ 11;
+   }
+   export inline namespace {
+ 11;
+   }
+   export/* test */inline namespace {
+ 11;
+   }
+   inline export namespace {
+ 11;
+   }
  
/* invalid namespaces use block indent */
namespace test test2 {
***
*** 4509,4514 
--- 4521,4538 
inline/* test */namespace {
11;
}
+   export namespace {
+   11;
+   }
+   export inline namespace {
+   11;
+   }
+   export/* test */inline namespace {
+   11;
+   }
+   inline export namespace {
+   11;
+   }
  
/* invalid namespaces use block indent */
namespace test test2 {
*** ../vim-9.0.1425/src/version.c   2023-03-23 15:45:42.808274880 +
--- src/version.c   2023-03-24 19:22:48.867902719 +
***
*** 697,698 
--- 697,700 
  {   /* Add new patch number below this line */
+ /**/
+ 1426,
  /**/

-- 
FATHER:Did you kill all those guards?
LAUNCELOT: Yes ...  I'm very sorry ...
FATHER:They cost fifty pounds each!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// 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/20230324192613.257A91C0655%40moolenaar.net.

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

On 23/03/24 10:45 AM, Bram Moolenaar wrote:

You might want to store the hash number with the function to avoid the
overhead of computing it.

This still needs to be done. To make sure I understand,
this is saving `hash_hash(name)` in ufunc_T and has_profiling has an
additional argument which is the hash. And if this argument is zero
then the hash would be computed in has_profiling.

I haven't looked at the PR yet, but I would think that as soon as you
have the function pointer, you can use the field that has the hash
value.  It is based on the function name, which doesn't change.  Thus it
needs to be computed only once.
Right, that's what I meant . After thinking about it a bit more, I went 
ahead and
implemented something, and pushed it last night, as you'll see. Caching 
the hash

is an easily detected improvement.

-ernie



However, if you mean the hash value of the pattern, then it would be
stored in "struct debuggy".  Obviously it depends on what key you use
for the hash table.



--
--
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/af7cbe90-fcbf-83ec-1a70-fe58dc9c076a%40raelity.com.

Re: map() slows down dramatically after vim running a while

[Bram Moolenaar]

> > You might want to store the hash number with the function to avoid the
> > overhead of computing it.
> 
> This still needs to be done. To make sure I understand,
> this is saving `hash_hash(name)` in ufunc_T and has_profiling has an
> additional argument which is the hash. And if this argument is zero
> then the hash would be computed in has_profiling.

I haven't looked at the PR yet, but I would think that as soon as you
have the function pointer, you can use the field that has the hash
value.  It is based on the function name, which doesn't change.  Thus it
needs to be computed only once.

However, if you mean the hash value of the pattern, then it would be
stored in "struct debuggy".  Obviously it depends on what key you use
for the hash table.

> >The overhead of looking up the key in the
> > table can't be avoided.  Also, when more function names are being cached
> > updating the hash table can also take a noticable amount of time.
>
> Yes, but it also would usually indicate that the table has been very
> useful.
> 
> I don't know most use cases; does the number of things being profiled
> change dynamically or very often?

That completely depends on what you are doing.  Assuming you first start
Vim and all plugins are loaded before you start profiling, then more
plugins would be loaded when you access files with a certain filetype.

Assuming you make changes (to scripts and/or source code) then Vim needs
to restart before you measure another profile.  Just make sure you use
the same order of commands each time, otherwise results might not be
showing the effect of your changes correctly.

-- 
Overflow on /dev/null, please empty the bit bucket.

 /// 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/20230324174502.891CA1C0660%40moolenaar.net.

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

FYI, back to where the latest profiler work started (after nsec clock)

The goal: compare performance "map(in, 'v:val')" vs "map(in, Map1)". Map1 is
    def Map1(_, val: number): number
    return val
    enddef
Turns out for processing a list with 3 items, 1.049 usec vs 1.590 usec;
at least that's the current results. (And not 1.166 vs 103)

Current vim:
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.608  0.625  0.641  0.999  0.957  0.954  1.237  1.179  1.166 : 
map(in, 'v:val')   ###-2
  0.068  0.072  0.071  0.071  0.068  0.069  0.070  0.070  0.070 : 
result = []   ###-4
  0.144  0.151  0.146  0.171  0.166  0.164  0.194  0.190  0.189 : in = 
input->copy()   ###-5
  2.784  6.023 10.140 27.808 36.471 45.324 77.819 92    103 : 
map(in, Map1)   ###-6


Upgraded function profiling patch
  0.599  0.574  0.568  0.902  0.795  0.807  1.121  1.066  1.049 : 
map(in, 'v:val')   ###-2
  0.071  0.072  0.071  0.072  0.069  0.071  0.071  0.070  0.070 : 
result = []   ###-4
  0.152  0.151  0.149  0.179  0.175  0.173  0.200  0.200  0.205 : in = 
input->copy()   ###-5
  0.807  0.771  0.723  1.179  1.182  1.165  1.663  1.598  1.590 : 
map(in, Map1)   ###-6


-ernie

On 23/03/23 7:31 PM, Ernie Rael wrote:

Opened draft PR: https://github.com/vim/vim/pull/12192
Initial results are promising, one measure is how few loops are
required for the results to stabilize.
And the results show *faster times* when user defined functions
are involved. It's interesting how good that feels, even though
it doesn't mean anything is actually running faster in production.

On 23/03/23 8:19 AM, Bram Moolenaar wrote:

Ernie Rael wrote:

You might want to store the hash number with the function to avoid the
overhead of computing it.


This still needs to be done. To make sure I understand,
this is saving `hash_hash(name)` in ufunc_T and has_profiling has an
additional argument which is the hash. And if this argument is zero
then the hash would be computed in has_profiling.


   The overhead of looking up the key in the
table can't be avoided.  Also, when more function names are being cached
updating the hash table can also take a noticable amount of time.
Yes, but it also would usually indicate that the table has been very 
useful.


I don't know most use cases; does the number of things being profiled
change dynamically or very often?

-ernie
--
--
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/911e2e0b-ab7b-8d34-e205-6c6cbeea1cc8%40raelity.com 
.


--
--
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/f61e3ca8-180e-85c7-b050-24a7f7203b6d%40raelity.com.

Re: [vim/vim] :help iccf does not work :-( (Issue #12186)

[Marvin Renich]

* Christian Brabandt  [230323 18:19]:
> I downloaded the `vim-runtime` Debian bullseye [package
> ](https://packages.debian.org/bullseye/all/vim-runtime/download). It
> is compressed of size 6MB. uncompressed 35MB.
> `/usr/share/vim/vim82/doc` alone has 8.6MB.  I then removed everything
> except for `/usr/share/doc` and `/usr/share/vim/vim82/doc`, and
> packaged it back as tar.xz package (which seems to be used by the
> Debian package internally). The new archive was then 2MB.  
> 
> That does not seem too bad, also I am still surprised it is that much
> documentation.
> 
> In comparison, the vim-tiny package is 700K, the `vim-tiny` binary has
> 1.4MB. Okay that is still significant less than just the hypothetical
> vim-help package, so maybe not such a good idea after all.

I was about to suggest that vim-tiny include its own copy of uganda.txt,
which vim-runtime would then divert like it does for help.txt, but I
think the best solution is just to move uganda.txt into vim-common.  It
increases the installed size of vim-tiny and dependencies by only 13k,
makes uganda.txt available to all versions of vim, and is trivial to do
(alright, maybe there is some packaging trickiness when moving an
existing file from one package to another, but it is doable).

...Marvin

-- 
-- 
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/ZB19QgyEQoCfQgSe%40basil.wdw.