PureBasic 6.40 beta 2 is ready, surprise inside !

[PeDe]

Raspberry Pi 500, Raspberry Pi OS, arm64 (Debian 13)

With the RaspPi, it's a little different:

Code: Select all

                              v6.30    v6.40b2
Litteral assign:              35 ms    77 ms -
Big litteral assign:         327 ms   129 ms +
Ucase litteral assign:      3270 ms  3029 ms +
Ucase assign:                440 ms   377 ms +
Ucase complex assign:       1065 ms   908 ms +
Str assign:                   75 ms    82 ms -
Str concat:                  207 ms   411 ms -
Final length = 264292
Large concat:                144 ms    33 ms +
Comparison dynamic buffer:   108 ms   123 ms -
Procedure with strings call: 320 ms   388 ms -
Finished

Peter

[Jacobus]

I repeated the test on both 64-bit versions to highlight the results. Two values ​​are better with PB 6.30.
Result in one image:

[Fred]

Raspberry Pi 500, Raspberry Pi OS, arm64 (Debian 13)

With the RaspPi, it's a little different:

Code: Select all

                              v6.30    v6.40b2
Litteral assign:              35 ms    77 ms -
Big litteral assign:         327 ms   129 ms +
Ucase litteral assign:      3270 ms  3029 ms +
Ucase assign:                440 ms   377 ms +
Ucase complex assign:       1065 ms   908 ms +
Str assign:                   75 ms    82 ms -
Str concat:                  207 ms   411 ms -
Final length = 264292
Large concat:                144 ms    33 ms +
Comparison dynamic buffer:   108 ms   123 ms -
Procedure with strings call: 320 ms   388 ms -
Finished

Peter

Mimalloc is disabled on RaspPI for now, that's probably why it's similar for alloc stuff. I will try to activate it but I got some build issue with mimalloc itself so stay tuned.

[Fred]

A picture with normalized values even better!

It is weird that some use cases are only 2x better?
Does that mean it was already optimized or there is still room for improvement in 6.40?

Well, 2x better is huge, no ? The old system wasn't that bad perfomance wise, but it has some limitation and some very hacky implementation which made the maintenance hard. Also when the Thread mode was enabled (which is for most apps nowaday) there was an extra performance hit. Now, the perfs are the same in thread and non-threaded mode.

The benchmark doesn't include string functions, but some are much faster, like Len(), Right(), RSet(), Mid(), etc. Basically having an instant length info is very useful for a lot of commands.

[skywalk]

Ok, I will redo my split() and join() speed tests, but many years ago it was 600x faster with comparememorystring() vs native PB string calls.
Thanks for clarifying where the new 2x comes from.

[Mindphazer]

On my Mac (M4 Pro, MacOS 26.3.1)

PB 6.30

Code: Select all

Litteral assign: 30 ms
Big litteral assign: 292 ms
Ucase litteral assign: 713 ms
Ucase assign: 112 ms
Ucase complex assign: 269 ms
Str assign: 34 ms
Str concat: 84 ms
Final length = 264292
Large concat: 114 ms
Comparison dynamic buffer: 19 ms
Procedure with strings call: 93 ms

PB 6.40b2

Code: Select all

Litteral assign: 31 ms
Big litteral assign: 43 ms
Ucase litteral assign: 497 ms
Ucase assign: 60 ms
Ucase complex assign: 158 ms
Str assign: 28 ms
Str concat: 191 ms
Final length = 264292
Large concat: 4 ms
Comparison dynamic buffer: 24 ms
Procedure with strings call: 108 ms

[Fred]

Can you test with threadsafe mode activated to see if there is some diffs ?

[threedslider]

Hi all,

Without debugger

6.30 :

Code: Select all

Litteral assign: 90 ms
Big litteral assign: 301 ms
Ucase litteral assign: 735 ms
Ucase assign: 117 ms
Ucase complex assign: 248 ms
Str assign: 65 ms
Str concat: 112 ms
Final length = 264292
Large concat: 81 ms
Comparison dynamic buffer: 33 ms
Procedure with strings call: 218 ms
Finished

6.40 b2 :

Code: Select all

Litteral assign: 26 ms
Big litteral assign: 36 ms
Ucase litteral assign: 356 ms
Ucase assign: 45 ms
Ucase complex assign: 102 ms
Str assign: 26 ms
Str concat: 146 ms
Final length = 264292
Large concat: 7 ms
Comparison dynamic buffer: 39 ms
Procedure with strings call: 117 ms
Finished

[threedslider]

PB 6.21 is a bit faster than the PB 6.30

Code: Select all

Litteral assign: 76 ms
Big litteral assign: 275 ms
Ucase litteral assign: 719 ms
Ucase assign: 110 ms
Ucase complex assign: 241 ms
Str assign: 64 ms
Str concat: 112 ms
Final length = 264292
Large concat: 81 ms
Comparison dynamic buffer: 33 ms
Procedure with strings call: 223 ms
Finished

[minimy]

Just to know PB6.02
I think it depends a lot on the CPU your PC has.

Code: Select all

Litteral assign: 100 ms
Big litteral assign: 493 ms
Ucase litteral assign: 1050 ms
Ucase assign: 178 ms
Ucase complex assign: 406 ms
Str assign: 94 ms
Str concat: 174 ms
Final length = 264292
Large concat: 236 ms
Comparison dynamic buffer: 38 ms 🔝
Procedure with strings call: 290 ms

Code: Select all

6.40b2
Litteral assign: 94 ms
Big litteral assign: 84 ms
Ucase litteral assign: 472 ms
Ucase assign: 54 ms
Ucase complex assign: 128 ms
Str assign: 66 ms
Str concat: 210 ms
Final length = 264292
Large concat: 9 ms
Comparison dynamic buffer: 50 ms
Procedure with strings call: 303 ms
Finished

[idle]

looks good and works with PBScript VM too.

Litteral assign: 23 ms
Big litteral assign: 35 ms
Ucase litteral assign: 513 ms
Ucase assign: 59 ms
Ucase complex assign: 145 ms
Str assign: 30 ms
Str concat: 141 ms
Final length = 264292
Large concat: 10 ms
Comparison dynamic buffer: 30 ms
Procedure with strings call: 110 ms
Finished

[Cezary]

And Now for Something Completely Different...

I have a problem with ContainerGadget, similar to the one described here:

viewtopic.php?t=86735

Is there a chance to do something about this before the 6.40 release? Or maybe I'm doing something wrong?

Code: Select all

OpenWindow(0, 200, 200, 220, 150, "test",  #PB_Window_MinimizeGadget | #PB_Window_TitleBar)
PanelGadget(1, 0, 0, 200, 120)
AddGadgetItem(1, -1, "Tab1")
ContainerGadget(3, 20, 20, 100, 50)
TextGadget(4, 20, 20, 50, 20, "text1")
CloseGadgetList()
TextGadget(5, 140, 40, 50, 20, "text2")
CloseGadgetList()
Repeat
Until #PB_Event_CloseWindow = WaitWindowEvent()

Desktop: Windows 11 x64

[Fred]

Why don't you create a proper bug report ?

[breeze4me]

And Now for Something Completely Different...

I have a problem with ContainerGadget, similar to the one described here:

viewtopic.php?t=86735

Is there a chance to do something about this before the 6.40 release? Or maybe I'm doing something wrong?

Code: Select all

OpenWindow(0, 200, 200, 220, 150, "test",  #PB_Window_MinimizeGadget | #PB_Window_TitleBar)
PanelGadget(1, 0, 0, 200, 120)
AddGadgetItem(1, -1, "Tab1")
ContainerGadget(3, 20, 20, 100, 50)
TextGadget(4, 20, 20, 50, 20, "text1")
CloseGadgetList()
TextGadget(5, 140, 40, 50, 20, "text2")
CloseGadgetList()
Repeat
Until #PB_Event_CloseWindow = WaitWindowEvent()

Desktop: Windows 11 x64

Unlike a frame gadget, a container gadget is not transparent, so it is normal.

[Cezary]

Why don't you create a proper bug report ?

I somehow thought this was related to the beta version fixes. I've corrected myself now, sorry.