PureBasic 6.40 alpha 3 is ready, surprise inside !

[NoahPhense]

Hi Fred and Core Dev Team, (It's been a few since I made a post.)

Maybe I've had too many beers, but the title bar of this alpha/beta, may be a little misconstrued.

It's called alpha, the download area calls it beta. Personally, you could call it Diet Coke, and I will be installing it. Just throwing this out there.

With that said .. there's an image.



Team, I hope you and yours have had some wonderful holidays.

Cheers!

np

ps -- 2000 posts, I was an "addict" long before this .. meh

[marcoagpinto]

2026-01-31: alpha 3 is available for Windows x64 ! A few more bugs has been fixed, and a new StringBuilder library has been added for very fast string concatenation ! Here is a small example:

Code: Select all

a$ = "Hello, World !"
CreateStringBuilder(0, 64000)
For l = 1 To 2000
  AppendStringBuilderString(0, a$)
Next
b$ = FinishStringBuilder(0)

Don't hesitate to test this version if you can as we believe it's ready for larger tests.

What is this StringBuilder command?

Aren't all string operations under the hood?

Code: Select all

a$="Hello World!"
b$=""
for f=1 to 2000
    b$=b$+a$
next f

Thanks!

[threedslider]

This code i have modified a little to one million iteration :

Code: Select all

a$ = "Hello, World !"
CreateStringBuilder(0, 64000)

i = ElapsedMilliseconds()
For l = 1 To 1000000
  AppendStringBuilderString(0, a$)
Next
b$ = FinishStringBuilder(0)
o = ElapsedMilliseconds()

Debug Str(o-i) + " ms"

It gives me 62 ms ! Wow very good

[Little John]

The problem is spreading this code as a "tip" around the forum, which will lead to people blindly using it thinking they are doing a clever optimization without understanding the details. And then if we do change something, we have to deal with the complaints again. And all that for an "optimization" that is not even worth that word.

Freak, I agree with all this you've said, about this workaround that ChrisR and fryquez discussed. But I think that's more reason for a native "UpdateStringLength" or "ResetStringLength" command. Even if it's just doing a PeekS() internally! Then it could be optimized in the future, or string lib internals could be reworked, automatic benefits for the user with zero changes to the user's code...

...

...

... also I think it makes code cleaner than unexplained Var = PeekS(@Var) scattered around

I agree with you, kenmo.

[mk-soft]

Hi Fred and Core Dev Team, (It's been a few since I made a post.)

Maybe I've had too many beers, but the title bar of this alpha/beta, may be a little misconstrued.

It's called alpha, the download area calls it beta. Personally, you could call it Diet Coke, and I will be installing it. Just throwing this out there.

Has already been asked. However, the web page will not be rebuilt for the special case "Alpha".
It is the first time that an alpha version is provided for testing.

[mk-soft]

Personally, I think it would be good to let us play with this prefix, but it would be better with an official guarantee in its integrity. Then, it's the developer's responsibility to know what they're doing
There is few points in its favor, in the last 2 post here

I apologize in advance if I shouldn't, but someone sent me this macro recently, the fastest.
But the debate should not be about speed, PeekS is fast enough.

If we shouldn't do it that way, then right (ThreadSafe) how we shouldn't do it

Code: Select all

CompilerIf #PB_Compiler_Version >= 640
  Threaded *_string
  Macro UpdateStringLength(String)
    *_string = @String : If *_string : PokeI(*_string - SizeOf(Integer), MemoryStringLength(*_string)) : EndIf
  EndMacro
CompilerElse
  Macro UpdateStringLength(String)
    ;
  EndMacro
CompilerEndIf

[freak]

The problem is spreading this code as a "tip" around the forum, which will lead to people blindly using it thinking they are doing a clever optimization without understanding the details. And then if we do change something, we have to deal with the complaints again. And all that for an "optimization" that is not even worth that word.

Freak, I agree with all this you've said, about this workaround that ChrisR and fryquez discussed. But I think that's more reason for a native "UpdateStringLength" or "ResetStringLength" command. Even if it's just doing a PeekS() internally! Then it could be optimized in the future, or string lib internals could be reworked, automatic benefits for the user with zero changes to the user's code...

...

...

... also I think it makes code cleaner than unexplained Var = PeekS(@Var) scattered around

If you want to write clean, future proof code, you should use AllocateMemory() for your memory buffers instead of misusing a string as a memory buffer that you can write to. If you think about it, THAT was the initial reliance on undocumented internals that you all have been using and it is breaking now because the internals have changed.

This would be the correct, future proof (and past proof) way to write this. It works no matter what the PB internals think a string should look like because it does not interact with the string variable in any way other than through documented string commands:

Code: Select all

*Buffer = AllocateMemory(#MAX_PATH * SizeOf(Character))
If *Buffer
  Length = GetModuleFileName_(GetModuleHandle_(#Null$), *Buffer, #MAX_PATH-1)  
  PureBasicPath$ = PeekS(*Buffer, Length)
  FreeMemory(*Buffer)
EndIf

Adding an official "UpdateStringLength()" command would require documenting the current way the string manager functions internally and therefore making it an official part of the API that cannot be changed easily anymore (how do you document a command without explaining why it would be needed?).

Using PeekS() is a good workaround that is still fairly future proof and does not need much change to existing code. It is a good compromise in my opinion of keeping things simple and flexible without having to make internal things part of the documented API.

And to those who think it is not optimized enough: Look at the example that is mostly thrown around here in the discussion: GetModuleFileName_()! This is a command that you call ONCE in your program (and there is a PB command to replace it btw). Stop this obsessing over micro-optimizations and focus on your program logic where it really counts!

[Little John]

If you want to write clean, future proof code, you should use AllocateMemory() for your memory buffers instead of misusing a string as a memory buffer that you can write to. If you think about it, THAT was the initial reliance on undocumented internals that you all have been using and it is breaking now because the internals have changed.

You are right.

[User_Russian]

You can use a fixed string with the API, and then you don't need to update its length.

Code: Select all

Path${#MAX_PATH}
GetModuleFileName_(GetModuleHandle_(#Null$), @Path$, #MAX_PATH)
MessageRequester(""+Len(Path$), Path$, 0)

I wrote here about updating the string length viewtopic.php?p=650578#p650578

[kenmo]

If you want to write clean, future proof code, you should use AllocateMemory() for your memory buffers instead of misusing a string as a memory buffer that you can write to.

Yes, true!

[idle]

if there are other circumstances where the length poses an issue requiring a fix I'd look at using the msb of the length to mark a string as dirty so the internal len function can fallback to scan and reset it.
so when passing a string to a function as **str flag it dirty, or is set with space() flag it dirty.
The question is would it introduce undesired side effects? It also adds the cost of a branch and needs atomics to do it thread safe. It's a lot of work for not a real problem but it would providing backward compatibility.
A lot of users rely on s.s= space(#maxpath) for windows api even though it's technically wrong and doubly so without using the returned length from the api, it just happens to work on windows.

The main issues with the speed of PB string processing has always been due to how it appends a string in a loop.
which isn't such an easy fix from the compiler perspective, it could be fixed by either look ahead and back tracing, deferred where you build two blocks at the same time and choose the block at closure or subsequent use of the string within the block or as a post generation peephole parse. Deferred is probably the better option to bolt on but its still not so easy to do.

PB 6.30 c backend, what you get vs what you want and there is no optimization parse in gcc that could fix it either that I'm aware of. So use the stringbuilder going forward or offer Fred $$$ to suffer the torment, pain and gnashing of teeth to implementing a compiler parse to fix it.

Code: Select all

Global s1.s  
Global s2.s   
Global l1,l2 

s1 = "hello" 
s2 = "world" 

st = ElapsedMilliseconds() 

For a =0 To 10000 ;s1+s2 blows out copying s1 
  !SYS_PushStringBasePosition();
  !SYS_CopyString(g_s1);
  !SYS_CopyString(g_s2);
  !SYS_AllocateString4(&g_s1,SYS_PopStringBasePosition());
Next   

et = ElapsedMilliseconds() 
l1 = Len(s1) 

s1 = "hello" 
s2 = "world" 

st1 = ElapsedMilliseconds()

!SYS_PushStringBasePosition();    s1+2s doesn't blow out copying s1 
For a = 0 To 10000
  !SYS_CopyString(g_s2);
Next 
!SYS_CopyString(g_s2);
!SYS_AllocateString4(&g_s1,SYS_PopStringBasePosition());

et1 = ElapsedMilliseconds() 
l2 = Len(s1) 

out.s = Str(et-st) + " " + Str(et1-st1) + " " + Str(l1) + " " + Str(l2)
MessageRequester("test",out) 

At least We have the Stringbuilder option to mitigate it, though it would be great if it could be addressed in the compiler itself one day.