Strings.. Objects or not???

  • Thread starter Thread starter Rigga
  • Start date Start date
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!
************************************************
Tom Spink said:
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
Click to expand...
 
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!
************************************************
 
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
 
Cowboy said:
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!
Click to expand...

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.
 
Herfried said:
Why not? Both string objects are pointing to the same "constant".
Click to expand...

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/
 
Michael Giagnocavo said:
Well, you *can* do it, but most likely it'll mess things up in other
calculations on strings in your apps...
Click to expand...

You can't do it in safe, managed code outside mscorlib which doesn't
use reflection - is that better? ;)
 
Lucky Carl said:
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/
Click to expand...

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?
 
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
 
* Lucky Carl said:
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/
Click to expand...

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.
 
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
 
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
 
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? ;)
Click to expand...

Sure, just wanted that to be clear :)

-mike
 
Cor Ligthert 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).
Click to expand...

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.
 
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
 
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
 
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
 
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

guy said:
err. doing this on an intel chip is a 1 (one) assembler instruction! I
Click to expand...
cant remeber the opcode, years since i used it, but on a Z80 (remember
them?) the assembler instruction was CPIR i believe - hardy inefficient!
 
Cor Ligthert said:
We know that the immutability of a string takes time
Click to expand...

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?
Click to expand...

Not really, no.
 
Cor is right.
Click to expand...

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
Click to expand...

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.
 
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
 
Back
Top