* Alexandru <alexandru.dadalau@meshparts.de>
| My string was 35k chars long. In my code I set the entry's variable to
| this string. The time needed to complete the action is the order of
| magnitude of 1 second.

| pack [entry .e -textvariable ::myvar]
| set s [join [lrepeat 35000 "a"] ""]
| set ::myvar $s

| Can you confirm this behavior?

No:
pack [entry .e -textvariable ::myvar]
update
set s [join [lrepeat 35000 "a"] ""]
(curious: why not simply 'string repeat'?)
time { set ::myvar $s }
=>
4579 microseconds per iteration

Note that if you run that interactively, the printing of the result string
to the console may take some time, too.

% info patchlevel
8.6.11
% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(engine) = Tcl
tcl_platform(machine) = x86_64
tcl_platform(os) = Linux
tcl_platform(osVersion) = 5.3.18-59.27-default
tcl_platform(pathSeparator) = :
tcl_platform(platform) = unix
tcl_platform(pointerSize) = 8
tcl_platform(threaded) = 1
tcl_platform(user) = ralf
tcl_platform(wordSize) = 8

R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

I just realized, that putting very large string into entry is very slow.

My string was 35k chars long. In my code I set the entry's variable to this string. The time needed to complete the action is the order of magnitude of 1 second.

pack [entry .e -textvariable ::myvar]
set s [join [lrepeat 35000 "a"] ""]
set ::myvar $s

Can you confirm this behavior?

Thanks
Alexandru

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexandru <alexandru.dadalau@meshparts.de> wrote:

Hi,

I just realized, that putting very large string into entry is very
slow.

My string was 35k chars long. In my code I set the entry's variable
to this string. The time needed to complete the action is the order
of magnitude of 1 second.

In addition to what Ralf indicated, is there some reason why you are
inserting such large strings into entries? An entry does not support
word wrap and attempting to actually use a display of a 35k character
string in an entry would be a UI nightmare.

An entry that contains a string longer than the width of the entry
itself begins to become a pain in the a** even if only a small part is obscured. The longer the string, the bigger the pain. With 35k
characters, almost all characters of the string will be off one edge or
the other, and invisible.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Mittwoch, 20. Oktober 2021 um 20:13:51 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Hi,

I just realized, that putting very large string into entry is very
slow.

My string was 35k chars long. In my code I set the entry's variable
to this string. The time needed to complete the action is the order
of magnitude of 1 second.

In addition to what Ralf indicated, is there some reason why you are inserting such large strings into entries? An entry does not support
word wrap and attempting to actually use a display of a 35k character
string in an entry would be a UI nightmare.

An entry that contains a string longer than the width of the entry
itself begins to become a pain in the a** even if only a small part is obscured. The longer the string, the bigger the pain. With 35k
characters, almost all characters of the string will be off one edge or
the other, and invisible.

I already taken care of that. The long string is now cut if longer than 100 chars.
But still, I can think of another situation where this could happen.
The question is still, why it's so slow? Aside from any UI considerations.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ralf Fassel schrieb am Mittwoch, 20. Oktober 2021 um 18:09:25 UTC+2:

* Alexandru <alexandr...@meshparts.de>
| My string was 35k chars long. In my code I set the entry's variable to
| this string. The time needed to complete the action is the order of
| magnitude of 1 second.

| pack [entry .e -textvariable ::myvar]
| set s [join [lrepeat 35000 "a"] ""]
| set ::myvar $s

| Can you confirm this behavior?
No:
pack [entry .e -textvariable ::myvar]
update
set s [join [lrepeat 35000 "a"] ""]
(curious: why not simply 'string repeat'?)
time { set ::myvar $s }

4579 microseconds per iteration

Note that if you run that interactively, the printing of the result string
to the console may take some time, too.

% info patchlevel
8.6.11
% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(engine) = Tcl
tcl_platform(machine) = x86_64
tcl_platform(os) = Linux
tcl_platform(osVersion) = 5.3.18-59.27-default
tcl_platform(pathSeparator) = :
tcl_platform(platform) = unix
tcl_platform(pointerSize) = 8
tcl_platform(threaded) = 1
tcl_platform(user) = ralf
tcl_platform(wordSize) = 8

R'

What is your OS?
I'm on Windows 10, 64 bit

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexandru <alexandru.dadalau@meshparts.de> wrote:

Rich schrieb am Mittwoch, 20. Oktober 2021 um 20:13:51 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Hi,

I just realized, that putting very large string into entry is very
slow.

My string was 35k chars long. In my code I set the entry's
variable to this string. The time needed to complete the action
is the order of magnitude of 1 second.

In addition to what Ralf indicated, is there some reason why you are
inserting such large strings into entries? An entry does not
support word wrap and attempting to actually use a display of a 35k
character string in an entry would be a UI nightmare.

An entry that contains a string longer than the width of the entry
itself begins to become a pain in the a** even if only a small part
is obscured. The longer the string, the bigger the pain. With 35k
characters, almost all characters of the string will be off one edge
or the other, and invisible.

I already taken care of that. The long string is now cut if longer
than 100 chars. But still, I can think of another situation where
this could happen. The question is still, why it's so slow? Aside
from any UI considerations.

See my other response asking if you were using the Tcl console window.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexandru <alexandru.dadalau@meshparts.de> wrote:

Ralf Fassel schrieb am Mittwoch, 20. Oktober 2021 um 18:09:25 UTC+2:

* Alexandru <alexandr...@meshparts.de>
| My string was 35k chars long. ... In my code I set the entry's variable to >> | this string. The time needed to complete the action is the order of
| magnitude of 1 second.

| Can you confirm this behavior?
No:
pack [entry .e -textvariable ::myvar]
update
set s [join [lrepeat 35000 "a"] ""]
(curious: why not simply 'string repeat'?)
time { set ::myvar $s }

4579 microseconds per iteration

Note that if you run that interactively, the printing of the result
string to the console may take some time, too.


R'

What is your OS?
I'm on Windows 10, 64 bit

Were you using the Windows Tcl console (i.e., 'console show' from your
script)? And did you run your test commands above in that same
console?

If yes to both, then the time delay you saw was the console code
attempting to format the 35k character string for display. The Tcl
console that appears on windows from 'console show' (or from starting a
wish on windows) is quite slow dealing with large strings.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Mittwoch, 20. Oktober 2021 um 22:11:23 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Rich schrieb am Mittwoch, 20. Oktober 2021 um 20:13:51 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Hi,

I just realized, that putting very large string into entry is very
slow.

My string was 35k chars long. In my code I set the entry's
variable to this string. The time needed to complete the action
is the order of magnitude of 1 second.

In addition to what Ralf indicated, is there some reason why you are
inserting such large strings into entries? An entry does not
support word wrap and attempting to actually use a display of a 35k
character string in an entry would be a UI nightmare.

An entry that contains a string longer than the width of the entry
itself begins to become a pain in the a** even if only a small part
is obscured. The longer the string, the bigger the pain. With 35k
characters, almost all characters of the string will be off one edge
or the other, and invisible.

I already taken care of that. The long string is now cut if longer
than 100 chars. But still, I can think of another situation where
this could happen. The question is still, why it's so slow? Aside
from any UI considerations.

See my other response asking if you were using the Tcl console window.

I'm opening the console in advance and call a script using "source". There is no output to the console so that is not the reson. I'm aware that the console is slow on outputing long strings.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexandru <alexandru.dadalau@meshparts.de> wrote:

Rich schrieb am Mittwoch, 20. Oktober 2021 um 22:11:23 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Rich schrieb am Mittwoch, 20. Oktober 2021 um 20:13:51 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Hi,

I just realized, that putting very large string into entry is very
slow.

My string was 35k chars long. In my code I set the entry's
variable to this string. The time needed to complete the action
is the order of magnitude of 1 second.

In addition to what Ralf indicated, is there some reason why you are
inserting such large strings into entries? An entry does not
support word wrap and attempting to actually use a display of a 35k
character string in an entry would be a UI nightmare.

An entry that contains a string longer than the width of the entry
itself begins to become a pain in the a** even if only a small part
is obscured. The longer the string, the bigger the pain. With 35k
characters, almost all characters of the string will be off one edge
or the other, and invisible.

I already taken care of that. The long string is now cut if longer
than 100 chars. But still, I can think of another situation where
this could happen. The question is still, why it's so slow? Aside
from any UI considerations.

See my other response asking if you were using the Tcl console window.

I'm opening the console in advance and call a script using "source".
There is no output to the console so that is not the reson. I'm
aware that the console is slow on outputing long strings.

The source command will return the last string output by the last
command in the file it sources. Have you shown us the exact script you sourced? Because the script you /did/ show us most definitely outputs
a 35k character long string to the console.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Donnerstag, 21. Oktober 2021 um 06:08:10 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Rich schrieb am Mittwoch, 20. Oktober 2021 um 22:11:23 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Rich schrieb am Mittwoch, 20. Oktober 2021 um 20:13:51 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Hi,

I just realized, that putting very large string into entry is very
slow.

My string was 35k chars long. In my code I set the entry's
variable to this string. The time needed to complete the action
is the order of magnitude of 1 second.

In addition to what Ralf indicated, is there some reason why you are
inserting such large strings into entries? An entry does not
support word wrap and attempting to actually use a display of a 35k
character string in an entry would be a UI nightmare.

An entry that contains a string longer than the width of the entry
itself begins to become a pain in the a** even if only a small part
is obscured. The longer the string, the bigger the pain. With 35k
characters, almost all characters of the string will be off one edge
or the other, and invisible.

I already taken care of that. The long string is now cut if longer
than 100 chars. But still, I can think of another situation where
this could happen. The question is still, why it's so slow? Aside
from any UI considerations.

See my other response asking if you were using the Tcl console window.

I'm opening the console in advance and call a script using "source".
There is no output to the console so that is not the reson. I'm
aware that the console is slow on outputing long strings.

The source command will return the last string output by the last
command in the file it sources. Have you shown us the exact script you sourced? Because the script you /did/ show us most definitely outputs
a 35k character long string to the console.

Here is script (but really, you can trust my ability to recognize a 35k chars long string being or not being output to the console):

pack [entry .e -textvariable ::myvar]
set s [join [lrepeat 35000 "a"] ""]
set ::myvar $s
return

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Obermeier schrieb am Donnerstag, 21. Oktober 2021 um 11:46:04 UTC+2:

Am 21.10.2021 um 11:32 schrieb Ralf Fassel:

* Alexandru <alexandr...@meshparts.de>
| Ralf Fassel schrieb am Mittwoch, 20. Oktober 2021 um 18:09:25 UTC+2: --<snip-snip>--
| > tcl_platform(machine) = x86_64
| > tcl_platform(os) = Linux
| >
| > R'
| What is your OS?
| I'm on Windows 10, 64 bit

See above, Linux 64bit.

I get the same results on Windows:

% cat t.tcl
pack [entry .e -textvariable ::myvar]
set s [join [lrepeat 35000 "a"] ""]
set ::myvar $s
return
% wishpp
% time {source t.tcl}
11351 microseconds per iteration

% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(engine) = Tcl
tcl_platform(machine) = amd64
tcl_platform(os) = Windows NT
tcl_platform(osVersion) = 10.0
tcl_platform(pathSeparator) = ;
tcl_platform(platform) = windows
tcl_platform(pointerSize) = 8
tcl_platform(threaded) = 1
tcl_platform(user) = ralf
tcl_platform(wordSize) = 4

% info patchlevel
8.6.11

HTH
R'

Using Ralf's code above, I get 1811 microseconds on Windows8, 64-bit Tcl 8.6.10.
Paul

I got it now.
Sorry one thing I did differently: I pack the entry in advance. Afterwards I execute the script:

set s [join [lrepeat 35000 "a"] ""]
set ::myvar $s

954877 microseconds per iteration

Interestigly. If I execute the script a second time, it's much faster:
2964 microseconds per iteration

Finally, if I delete the content of the entry and execute the script, than it's slow again.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Alexandru <alexandru.dadalau@meshparts.de>
| Ralf Fassel schrieb am Mittwoch, 20. Oktober 2021 um 18:09:25 UTC+2: --<snip-snip>--
| > tcl_platform(machine) = x86_64
| > tcl_platform(os) = Linux
| >
| > R'
| What is your OS?
| I'm on Windows 10, 64 bit

See above, Linux 64bit.

I get the same results on Windows:

% cat t.tcl
pack [entry .e -textvariable ::myvar]
set s [join [lrepeat 35000 "a"] ""]
set ::myvar $s
return
% wishpp
% time {source t.tcl}
11351 microseconds per iteration

% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(engine) = Tcl
tcl_platform(machine) = amd64
tcl_platform(os) = Windows NT
tcl_platform(osVersion) = 10.0
tcl_platform(pathSeparator) = ;
tcl_platform(platform) = windows
tcl_platform(pointerSize) = 8
tcl_platform(threaded) = 1
tcl_platform(user) = ralf
tcl_platform(wordSize) = 4

% info patchlevel
8.6.11

HTH
R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 21.10.2021 um 11:32 schrieb Ralf Fassel:

* Alexandru <alexandru.dadalau@meshparts.de>
| Ralf Fassel schrieb am Mittwoch, 20. Oktober 2021 um 18:09:25 UTC+2: --<snip-snip>--
| > tcl_platform(machine) = x86_64
| > tcl_platform(os) = Linux
| >
| > R'
| What is your OS?
| I'm on Windows 10, 64 bit

See above, Linux 64bit.

I get the same results on Windows:

% cat t.tcl
pack [entry .e -textvariable ::myvar]
set s [join [lrepeat 35000 "a"] ""]
set ::myvar $s
return
% wishpp
% time {source t.tcl}
11351 microseconds per iteration

% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(engine) = Tcl
tcl_platform(machine) = amd64
tcl_platform(os) = Windows NT
tcl_platform(osVersion) = 10.0
tcl_platform(pathSeparator) = ;
tcl_platform(platform) = windows
tcl_platform(pointerSize) = 8
tcl_platform(threaded) = 1
tcl_platform(user) = ralf
tcl_platform(wordSize) = 4

% info patchlevel
8.6.11

HTH
R'

Using Ralf's code above, I get 1811 microseconds on Windows8, 64-bit Tcl 8.6.10.
Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 20.10.21 um 20:18 schrieb Alexandru:

I already taken care of that. The long string is now cut if longer than 100 chars.
But still, I can think of another situation where this could happen.
The question is still, why it's so slow? Aside from any UI considerations.

cascading realloc to accomodate the string?

Uwe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Paul Obermeier <obermeier@poSoft.de>
--<snip-snip>--
| > % wishpp
| > % time {source t.tcl}
| > 11351 microseconds per iteration
--<snip-snip>--

| Using Ralf's code above, I get 1811 microseconds on Windows8, 64-bit Tcl 8.6.10.

Yeah, my 'jupiter' is a 2012 core-i5, not the greatest rocket nowadays :-)))

R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)