Strings.. Objects or not???

[Cowboy \(Gregory A. Beamer\) [MVP]]

This is very true, but does not explain what is happening. The compiler
sees:

Dim x as String = "veg"
Dim y as String = "veg"

and says "hey, it is the same constant." Underneath the hood, some magic
happens. NOTE: This is actually the JIT compiler that does this magic and
not the initial IL compile. Tres kewl!

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

But let's not forget that they are immutable.... When you change the value
of a string object, the object is destroyed and a brand new one is created.

--
HTH,
-- Tom Spink, Über Geek

Woe be the day VBC.EXE says, "OrElse what?"

Please respond to the newsgroup,
so all can benefit

 

[Cowboy \(Gregory A. Beamer\) [MVP]]

See the app I posted in reponse to your intial question. The test app should
give you an idea of what is happening.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

 

[Michael Giagnocavo [MVP]]

Um, no. You *can't* "change the value" of a string object. You can

Well, you *can* do it, but most likely it'll mess things up in other
calculations on strings in your apps...

-mike

 

[Lucky Carl]

This is very true, but does not explain what is happening. The compiler
sees:

Dim x as String = "veg"
Dim y as String = "veg"

and says "hey, it is the same constant." Underneath the hood, some magic
happens. NOTE: This is actually the JIT compiler that does this magic and
not the initial IL compile. Tres kewl!

I hope whatever pattern matching algorithm for strings that is used is
efficient.

That means that any new string has to run through such a comparison to
determine whether it exists or not.

Whatever little bit of memory is conserved would seem small compared to the
amount of wasted cpu time in performing this operation.

 

[Lucky Carl]

Why not? Both string objects are pointing to the same "constant".

Ok, so if

string y1 = "abcdefghijklmnopqrstuvwxy"
string y2 = "abcdefghijklmnopqrstuvwxyz"

That means that y1 is created, then a search algorithm does a string search
all the way to 'y' and then says -- opps, gotta create a new object.

Man. Talk about /overhead/

 

[Jon Skeet [C# MVP]]

Well, you *can* do it, but most likely it'll mess things up in other
calculations on strings in your apps...

You can't do it in safe, managed code outside mscorlib which doesn't
use reflection - is that better?

 

[Jon Skeet [C# MVP]]

Ok, so if

string y1 = "abcdefghijklmnopqrstuvwxy"
string y2 = "abcdefghijklmnopqrstuvwxyz"

That means that y1 is created, then a search algorithm does a string search
all the way to 'y' and then says -- opps, gotta create a new object.

Man. Talk about /overhead/

It's done once per string, and I suspect it looks at the length and
hash of the string first.

So no, not that much overhead, really. Just how many string literals do
you have in your programs, anyway?

 

[Nick Malik]

It's done by the JIT Compiler... read the last word: COMPILER

It is done AT COMPILE TIME.

For a few milliseconds spent, the system saved me a little bit of memory.
Time well spent, I'd say.

--- Nick

 

[Herfried K. Wagner [MVP]]

Ok, so if

string y1 = "abcdefghijklmnopqrstuvwxy"
string y2 = "abcdefghijklmnopqrstuvwxyz"

That means that y1 is created, then a search algorithm does a string search
all the way to 'y' and then says -- opps, gotta create a new object.

Man. Talk about /overhead/

I don't think that this is the case. Instead, I assume that the scanner
will add the string literals to a symbol table and create according references
to the symbols in the table if a string literal occurs more than once.

 

[Cor Ligthert]

Hi Herfried,

Of course is it takes time. When I see this kind of remarks, I always think
that those people who tell this are still thinking from an Ms-DOS kind of
operating systems without GUI. A GUI takes much more from an OS than those
loops in a simple table (that can even be optimized of course as you said).

We know that the immutability of a string takes time, thinking about that we
know that it takes maybe even more time than we think. (By the way, testing
for an existence is only needed when creating a string).

However, dotNet is not made for a Commodore 64 and even not for a PC1.

Just my thought about this.

Cor

 

[One Handed Man \( OHM - Terry Burns \)]

Hey I heard that they are bringing out Sinclair Spectrum.NET

LOL

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

 

[Michael Giagnocavo [MVP]]

Well, you *can* do it, but most likely it'll mess things up in other

You can't do it in safe, managed code outside mscorlib which doesn't
use reflection - is that better?

Sure, just wanted that to be clear

-mike

 

[Jon Skeet [C# MVP]]

We know that the immutability of a string takes time, thinking about
that we know that it takes maybe even more time than we think. (By
the way, testing for an existence is only needed when creating a
string).

Be careful here - the immutability of strings doesn't take any
resources at all; it's just a feature of there being no public methods
which change the contents. Interning of string literals is a separate
feature. While it requires immutability in order to be useful,
immutability doesn't require interning.

 

[Cor Ligthert]

Jon,

We know that the immutability of a string takes time, thinking about
this subject we know that it takes maybe even more time than we think to
create a string.

So better?

Cor

 

[Guest]

err. doing this on an intel chip is a 1 (one) assembler instruction! I cant remeber the opcode, years since i used it, but on a Z80 (remember them?) the assembler instruction was CPIR i believe - hardy inefficient!

guy

 

[One Handed Man \( OHM - Terry Burns \)]

Cor is right.

At the lower levels, when a string is matched agaist another two strings
being matched of 99 'z''s one followed by 1 and the other by 2 will take
longer to match than two similar strings both of length 10



--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

 

[One Handed Man \( OHM - Terry Burns \)]

Your showing your age, the Z80 came out around 1980, thats 24 years ago !

I remember because we used them in science club at school.



--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

err. doing this on an intel chip is a 1 (one) assembler instruction! I

cant remeber the opcode, years since i used it, but on a Z80 (remember
them?) the assembler instruction was CPIR i believe - hardy inefficient!

 

[Jon Skeet [C# MVP]]

We know that the immutability of a string takes time

In what way? How does immutability itself take time?

thinking about this subject we know that it takes maybe even
more time than we think to create a string.

So better?

Not really, no.

 

[Jon Skeet [C# MVP]]

Cor is right.

I disagree.

At the lower levels, when a string is matched agaist another two strings
being matched of 99 'z''s one followed by 1 and the other by 2 will take
longer to match than two similar strings both of length 10

But the point is that that is due to interning, not due to
immutability. Consider a system where strings were immutable, but
weren't interned: where would the slowdown be?

I don't disagree that there *is* a performance penalty (although I
believe it's insignificant). I disagree with the idea that that penalty
is due to immutability rather than due to interning.

 

[Cor Ligthert]

Thirth try,

We know that the immutability of a string can take more time when we concate
them when we do not use the stringbuilder, thinking about this subject we
know that it can take even more time than we maybe think to create a string.

Can this have your agreement?



(You would already know from me that as I wrote again in this thread that
this kind of needed time is real bs for me)



Cor