SmolStr has an Arc internally for large strings. This allows
cheap copies of large strings, but we lose that ability
when we convert the SmolStr to a &str and then reconstruct a
SmolStr from that slice.
I was hoping for some larger gains here, considering the impact
of this code change, but it only removes ~50k allocations,
while the impact on the runtime is not noticeable at all.
Still, I believe this is the right thing to do.
Before:
```
allocations: 2338981
Time (mean ± σ): 988.3 ms ± 17.9 ms [User: 690.2 ms, System: 206.4 ms]
Range (min … max): 956.4 ms … 1016.3 ms 10 runs
```
After:
```
allocations: 2287723
Time (mean ± σ): 989.8 ms ± 23.2 ms [User: 699.2 ms, System: 197.6 ms]
Range (min … max): 945.3 ms … 1021.4 ms 10 runs
```
Instead of cloning the vector on every iteration level, pass the
scope in and out of the visitation function and push/pop the element
there as needed. This way we can operate on a single vector that
gets moved around, which removes a few thousand memory allocations.
The speed impact is not measurable, as the code also triggers rowan
API that is much more allocation happy.
Still, I believe this patch is still merge-worthy as it also reduces
the code duplication a bit and is subjectively better, esp. from a
performance pov.
Instead of doing potentially multiple calls in the chained calls,
each of which would allocate in rowan, we now only call the iterator
function once and then leverage `find_map`. This is arguably even
more readable and it removes ~300k allocations and speeds up parsing.
Before:
```
Time (mean ± σ): 930.7 ms ± 15.1 ms [User: 678.7 ms, System: 165.5 ms]
Range (min … max): 906.4 ms … 956.3 ms 10 runs
allocations: 2339130
```
After:
```
Time (mean ± σ): 914.6 ms ± 22.7 ms [User: 649.6 ms, System: 174.5 ms]
Range (min … max): 874.8 ms … 946.3 ms 10 runs
allocations: 2017915
```
This is rarely used, but using Rc here like elsewhere allows us to
elide a few unneccessary memory allocations when copying such types.
The speed impact is not measurable though. With heaptrack I see that
we get rid of the last ~7600 allocations in my benchmark when cloning
Type.
This makes copying such types much cheaper and will allow us to
intern common struct types in the future too. This further
drops the sample cost for langtype.rs from ~6.6% down to 4.0%.
We are now also able to share/intern common struct types.
Before:
```
Time (mean ± σ): 1.073 s ± 0.021 s [User: 0.759 s, System: 0.215 s]
Range (min … max): 1.034 s … 1.105 s 10 runs
allocations: 3074261
```
After:
```
Time (mean ± σ): 1.034 s ± 0.026 s [User: 0.733 s, System: 0.201 s]
Range (min … max): 1.000 s … 1.078 s 10 runs
allocations: 2917476
```
This allows us to cheaply copy the langtype::Type values which
contain such a type. The runtime impact is small and barely noticable
but a sampling profiler shows a clear reduction in samples pointing
at langtype.rs, roughly reducing that from ~8.6% inclusive cost
down to 6.6% inclusive cost.
Furthermore, this allows us to share/intern common types.
Before:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 1.089 s ± 0.026 s [User: 0.771 s, System: 0.216 s]
Range (min … max): 1.046 s … 1.130 s 10 runs
allocations: 3152149
```
After:
```
Time (mean ± σ): 1.073 s ± 0.021 s [User: 0.759 s, System: 0.215 s]
Range (min … max): 1.034 s … 1.105 s 10 runs
allocations: 3074261
```
This removes a lot of allocations and speeds up the compiler step
a bit. Sadly, this patch is very invasive as it touches a lot of
files. That said, each individual hunk is pretty trivial.
For a non-trivial real-world example, the impact is significant,
we get rid of ~29% of all allocations and improve the runtime by
about 4.8% (measured until the viewer loop would start).
Before:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 664.2 ms ± 6.7 ms [User: 589.2 ms, System: 74.0 ms]
Range (min … max): 659.0 ms … 682.4 ms 10 runs
allocations: 4886888
temporary allocations: 857508
```
After:
```
Benchmark 1: ./target/release/slint-viewer ../slint-perf/app.slint
Time (mean ± σ): 639.5 ms ± 17.8 ms [User: 556.9 ms, System: 76.2 ms]
Range (min … max): 621.4 ms … 666.5 ms 10 runs
allocations: 3544318
temporary allocations: 495685
```
Updated the version from 1.1 to 1.2
Renamed the header to "Slint Royalty-free Desktop, Mobile, and Web Applications License"
Added definition of "Mobile Application" and grant of right
Moved "Limitations" to 3rd section and "License Conditions - Attributions" to 2nd section
Added flexibility to choose between showing "MadeWithSlint" as a dialog/splash screen or on a public webpage
Moved the para on copyright notices to section under "Limitations"
Just ignore the case where focus has more argument that planed as it has
been reported as an error earlier.
Also fix the error message for calling member function with the wrong
number of argument to not include the base in the count.
Fix#4883
As per API review:
- In the Rust and C++ API we use `set_nine_slice_edges` because the getter couldn't start with 9
- in english we spell number less than 10 with letters and this is a name
The problem is that we were taking the whole `repeated` field and as a
result we wouldn't see that the element was being repeated and that we
shouldn't have to lookup id within it
Fix#4683
Regression noticed in this line:
3f97d98bff/ui/tabs/downloads.slint (L77)
The following used to work:
```slint
import { Button, VerticalBox } from "std-widgets.slint";
export component Demo {
in property <[int]> mods;
VerticalBox {
alignment: start;
for xxx in true ? mods : [] : HorizontalLayout { alignment: center; Button { text: "OK!"; } }
}
}
```
But we fixed array conversion and this caused a regression with empty
array
If a branch that always return has a "void value" and the side that
doesn't return has a value, we need to synthetize a default value
so the struct is complete, even if that value is not used.
* Extend the cspell word list
* Remove those extensions from individual source files
* white-list licenses and such as we should not meddle with those
* Fix spelling
Resolve an image path to soemthing relative to the syntax node that
pulls it in if the path can not get resolved.
This typically happens in WASM as file existence is checked during image
resolution, which is not possible there.
Add some code to do platform-independent path processing.
This is necessary aas WASM does e.g. not have any absolute paths and
such and the compiler tended to produce wrong results in that case.
Side-effect: We no longer need to depend on `dunce`
This should in principle not be allowed, it should be relative to the
file itself.
Make it a warning, and at least, don't duplicate the globals
Fixes#2719
This improve the code coverage of syntax_text, so some adjustment had to
be made.
This may add more error in the main file, but this make it the same
behavior as for imported files and lsp who were already running these
passes all the time
Note, this goes against the gettext documentation's recommendation:
https://www.gnu.org/software/gettext/manual/gettext.html#Contexts
> Finding a canonical msgctxt string that doesn’t change over time can be hard.
> But you shouldn’t use the file name or class name containing the pgettext
> call – because it is a common development task to rename a file or a class,
> and it shouldn’t cause translator work.
