add a single byte to byte()

[Guoqi Zheng]

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the
value of that individual byte, if that byte is what I want, then I insert it
into the new byte(). How can I do it?

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

 

[Hal Rosser]

redim the array - and -
assign a byte to the new element

 

[Herfried K. Wagner [MVP]]

redim the array - and -
assign a byte to the new element

In this case, 'ReDim Preserve' is the way to go.

 

[David]

I am really do not know so much about byte/bit, etc.

Question, if I defined a byte(), how can I add a single byte to it?

what I want is that I have an array of bytes, I loop that array, look at the
value of that individual byte, if that byte is what I want, then I insert it
into the new byte(). How can I do it?

For resizable arrays, you really want to use
System.Collections.ArrayList. You can always convert back into an
ordinary byte() after you've filled the ArrayList with the contents you
want.

If you only need to add a single byte one time, then ReDim Preserve will
work fine, but it sounds like you're doing this in a loop, and
performance will be terrible if you rely on ReDim here.

 

[Hal Rosser]

Agreed

In this case, 'ReDim Preserve' is the way to go.
/>

 

[Cor Ligthert]

Guaoqi,

Assume you have a text and want it to set as Asci in a byte array, than you
get something as (roughly typed in this message so watch typos)

\\\\
dim myString as string = "Ik hoop dat dit helpt?"
dim ByteArr(mystring.length) as byte
for i as integer = 0 to mystring.length -1
ByteArr(i) = Cbyte(asc(mystrstring.substring(i,1)))
next
///

I hope this helps?

Cor

"Guoqi Zheng"
..

 

[Guoqi Zheng]

Thanks, it sounds like exactly what I am looking for. An arraylist then back
to byte()

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

 

[Jay B. Harlow [MVP - Outlook]]

David,
Just be aware that an ArrayList with bytes in it is going to cause a lot of
boxing & unboxing which may hurt performance.

I would consider an array of bytes & ReDim Preserve, only over allocate the
array, then keep track of how many actual elements are in the array. By over
allocate I mean allocate 50 elements in the array although there is only 40
actual elements in it.

I will check if I have a good example. I have posted one or two examples
previously.

Hope this helps
Jay

 

[Guoqi Zheng]

This solution sounds fine as well.

But if I allocate 500 elements, and I used only 30, how can I remove the
extra 470 from that byte(), by Redim Preserve? and will these extra 470
elements cost performance problem?

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

 

[Cor Ligthert]

Jay,

Your answer was my first answer as well, however I scratched it to make an
in my opinion nicer answer.

(I know it is not right to set a unicharacter to an asci value however as
sample goes this so easy)

The way you describe now is also in my opinion the best way to do it when
you do not know the length in advance.

Although an other alternative is of course doing it streaming.



Cor

 

[Jay B. Harlow [MVP - Outlook]]

Guoqi,

extra 470 from that byte(), by Redim Preserve?

I would use Redim Preserve, Array.Copy, or Buffer.BlockCopy.

and will these extra 470
elements cost performance problem?

1 allocation of 500 bytes followed by a Redim Preserve is going to perform
better then 30 Redim Preserves. And possible better then 30 boxes & unboxes.
The only real way to tell is to use a profiling tool to check.


Most of the time the overallocating will be the better performing (both
memory usage & speed wise). Sometimes the ArrayList & boxing may perform
acceptable.
Obviously if you know before hand how much space you will need or can make a
very good estimate you have a better chance of it.

Remember that reallocating (Redim preserve) in both cases means that a new
buffer needs to be defined, then the old buffer needs to be copied to the
new array.

Hope this helps
Jay

 

[David]

David,
Just be aware that an ArrayList with bytes in it is going to cause a lot of
boxing & unboxing which may hurt performance.

Actually, it wouldn't cause a lot of either, just once per byte, which
is trivial unless you're dealing with huge nested loops. Overallocating
an array is faster, but unless you are absolutely sure you'll never need
a larger array (and that might be the case here), what should be a very
simple loop starts looking much uglier than it needs to be.

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?

 

[Jay B. Harlow [MVP - Outlook]]

David,

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?

Yes I am. Which is why I stated "may hurt performance", then again today I
added to "the only real way to tell is to use a profiling tool to check".

Actually, it wouldn't cause a lot of either, just once per byte, which
is trivial unless you're dealing with huge nested loops.

Correct. You will have a box for each byte you put into the ArrayList. Plus
an Unbox for each byte you remove.

So if you have a lot of bytes you will have a lot of boxing. In other words
at least 1 box & unbox for each byte. Correct?

Hope this helps
Jay

 

[Cor Ligthert]

David,

Aren't you the one who constantly posts the 80/20 rule here, or am I
confusing you with somebody else?

And the other one in other words is me. I am the one who uses almost the
arraylist in samples for everything while others point mostly than too the
hashtable, (where I use than when it is needed earlier the sortedlist).

When it is about a byte array, than there should be a reason why it is a
byte array, because it is in my opinion an archaic piece of storage, altough
very good for serializing and deserializing. For those you loads the
bytearray streaming and you do not need to set a byte by byte to an array.

You can see in this thread a message from me which describes a bytearray
with ASCI chareacter, however for what I would directly use an arraylist
when it was really needed to get the full unicode in a char. (Although I
really cannot find a reason for that)

In my idea in this case when there is really a bytearray needed, than we
should never go to the arraylist, because than the one who does that has
never investigated his problem. Because the byte is the value type you take
as last to choose from when it is not streaming.

However when it should be a bytearray and you do not know the size however
know that the maximum is 400bytes, than you should not even redim it.
Probably you will loose with the code to redim more bytes than what you can
earn with that.

However just my idea.

Cor

 

[David]

David,

Yes I am. Which is why I stated "may hurt performance", then again today I
added to "the only real way to tell is to use a profiling tool to check".

Correct. You will have a box for each byte you put into the ArrayList. Plus
an Unbox for each byte you remove.

So if you have a lot of bytes you will have a lot of boxing. In other words
at least 1 box & unbox for each byte. Correct?

Yep, it increases O(n) as the number of bytes increases. It's a rare
app where such a thing is a major concern. Though, certainly, such apps
are out there.

 

[David]

David,


And the other one in other words is me. I am the one who uses almost the
arraylist in samples for everything while others point mostly than too the
hashtable, (where I use than when it is needed earlier the sortedlist).

When it is about a byte array, than there should be a reason why it is a
byte array, because it is in my opinion an archaic piece of storage, altough
very good for serializing and deserializing. For those you loads the
bytearray streaming and you do not need to set a byte by byte to an array.

You can see in this thread a message from me which describes a bytearray
with ASCI chareacter, however for what I would directly use an arraylist
when it was really needed to get the full unicode in a char. (Although I
really cannot find a reason for that)

In my idea in this case when there is really a bytearray needed, than we
should never go to the arraylist, because than the one who does that has
never investigated his problem. Because the byte is the value type you take
as last to choose from when it is not streaming.

OK, I'm honestly not sure if I'm understanding this correctly, but...

I don't see your reasoning here, largely because you don't seem to have
any. The issue is that you need to accumulate bytes, regardless of
where they're coming from (so streaming or not isn't really relevant).
Why do you think an arraylist shouldn't be used for accumulation here?
You state this as an absolute ("one who does that has never
investigated"), but never say why. If it's the performance issue, I'd
suggest that your concerns are misplaced, since it's highly unlikely the
performance hit is going to be noticeable.

However when it should be a bytearray and you do not know the size however
know that the maximum is 400bytes, than you should not even redim it.
Probably you will loose with the code to redim more bytes than what you can
earn with that.

OK, now that I understand, and disagree with completely. Passing around
an incomplete array, one whose length is not the same as the number of
valid entries, is a recipe for disaster. Sure, you'll remember what's
going on while you write this code, but six months later it's incredibly
easy to forget that you've got some other variable someplace telling you
what the "real length" of the array is.

This is the sort of premature optimization that the 80/20 rule is meant
to address. This suggested "fix" would greatly harm readability, and
add to performance only slightly, and I'd profile the hell out of an app
before I went that direction.

 

[Jay B. Harlow [MVP - Outlook]]

David,

Yep, it increases O(n) as the number of bytes increases. It's a rare
app where such a thing is a major concern. Though, certainly, such apps
are out there.

I question where you get "rare app" from! :-|

If the OPs function is being used regularly in a ASP.NET app I could see it
adversely effecting performance, as all those boxed bytes need to be GCed,
which increases the time spent in the GC. In addition to the increased time
the client may see waiting for the response itself from being processed...

ASP.NET apps are far from rare.

Of course one would really need to use tools such as ACT & CLR Profiler to
accurately determine if the boxed bytes were causing a problem or not.
Rather then using conjecture to suggest they do or do not. Hence "may hurt
performance" in my original comments, which I'm sure you will agree implies
may not.

My suggestion of avoiding the boxing altogether, if needed, is based on
reading the following:

http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpag/html/scalenet.asp

In addition to the following:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp

http://msdn.microsoft.com/library/d...y/en-us/dndotnet/html/highperfmanagedapps.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/vbnstrcatn.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchperfopt.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp

All of which describe methods of writing code that performs well.

Hope this helps
Jay

 

[David]

David,
I question where you get "rare app" from! :-|

If the OPs function is being used regularly in a ASP.NET app I could see it
adversely effecting performance, as all those boxed bytes need to be GCed,
which increases the time spent in the GC. In addition to the increased time
the client may see waiting for the response itself from being processed...

ASP.NET apps are far from rare.

Of course one would really need to use tools such as ACT & CLR Profiler to
accurately determine if the boxed bytes were causing a problem or not.
Rather then using conjecture to suggest they do or do not. Hence "may hurt
performance" in my original comments, which I'm sure you will agree implies
may not.

It's interesting that we don't seem to be disagreeing on anything
concrete here, just using different language that implies a different
level of concern. So let's make the question more concrete. In the
real world, how would you approach this problem? I'm really not quite
getting that precisely that from your comments (nor from mine, I'd add),
and that's the question that's actually interesting here.

Let's assume that this isn't the core function of the entire app, just
that on a few pages you need to filter input of unknown size (say
something uploaded from the user) and pass a byte array to another
assembly.

Do you
a) implement with array+fixup
b) implement with ArrayList, changing to array at a later
development cycle only if profiling suggests it
c) profile immediately to see the difference
d) something else I haven't thought of

In the real world, I'd almost definitely implement originally with
boxing. I very seldom declare arraylists, so I'd be using
CollectionBase, but it's the same concept. Then I'd switch to an array
implementation only if profiling during a later cycle suggested it.

Also, I'd probably switch to an array implementation inside the
collection class if I called the byte accumulation code from three or
more places, and to be honest I'd switch without profiling. That's evil
and wrong, but I'm being honest here. (Hopefully I'd have forced a
capacity parameter to the collection constructor, but I'd probably
forget).

There's two things I wouldn't do. I wouldn't profile immediately unless
this functionality was the absolutely primary action during multiple
responses. The profiler just isn't part of my day-to-day toolset. Also,
I would never implement with array fixup inside the loop or surrounding
the loop. I find array declarations to be far too error prone for that.

The interesting questions usually aren't "how do you do X", folks can
look that stuff up. What's interesting to me is "how do you approach
problem X"; how does one actually deal with these issues in day-to-day
work.

 

[Jay B. Harlow [MVP - Outlook]]

David,

So let's make the question more concrete. In the
real world, how would you approach this problem?

Unfortunately there is no where near enough information (here) to make an
informed decision on it. Hence my statement "may hurt performance" so the OP
could weigh the options on his actual requirements and make an informed
decision. Which via profiling may need to be changed.

If it was the core function of that class (UUENCODE class) I would probably
use the ByteBuffer class I started earlier, ByteBuffer functions very
similar to the System.Text.StringBuilder class in that it maintains a byte
array internally allowing you to append bytes or byte arrays on the end,
expanding the internal array as needed.

http://groups.google.com/groups?q=B...=#[email protected]&rnum=3

I would be choosing ByteBuffer for exactly the same reason I would choose
StringBuilder or ArrayList.

Notice that the UUENCODE class itself doesn't use any of the methods you
identified per se, however the ByteBuffer class itself does (encapsulation,
reuse).

Another factor I would consider before I actually decided which method to
use first (pre-profiling) would be how large a buffer I would normally work
with, and how often it changed.

For example, if I knew I would always need a fixed size buffer (based on the
length of an input string for example) and no reallocations were needed,
then obviously this discussion is moot. Or if I knew I could use a slightly
larger buffer, with a little slack, with a single reallocation at the end,
then a simple array would do.

There may be other considerations in the OPs needs that I don't have right
now...

Again it really would depend on the complete real requirements of the
problem.

d) something else I haven't thought of

Thinking about it, I would consider using a MemoryStream also, as it
effectively is an ArrayList or StringBuilder for bytes. In other words a
dynamic array of bytes, without the boxing.

In the real world, I'd almost definitely implement originally with
boxing. I very seldom declare arraylists, so I'd be using
CollectionBase, but it's the same concept. Then I'd switch to an array
implementation only if profiling during a later cycle suggested it.

Using a CollectionBase does not feel right here, as the buffer in question
seems like an implementation detail of the UUENCODE functionality, not a
collection of domain objects per se. I normally reserve CollectionBase
classes for collections of domain objects. FWIW a Domain object is the more
general term for business object.

Unless you were suggesting you would inherit from CollectionBase to
implement a ByteBuffer class.

Of course when we get to VB.NET 2005 (Whidbey due out in 2005), Using a
generic byte list would be an option also
(http://msdn2.microsoft.com/library/6sh2ey19.aspx).

Hope this helps
Jay

 

[Cor Ligthert]

David,

I don't see your reasoning here, largely because you don't seem to have
any. The issue is that you need to accumulate bytes, regardless of
where they're coming from (so streaming or not isn't really relevant).
Why do you think an arraylist shouldn't be used for accumulation here?
You state this as an absolute ("one who does that has never
investigated"), but never say why. If it's the performance issue, I'd
suggest that your concerns are misplaced, since it's highly unlikely the
performance hit is going to be noticeable.

An arraylist is not made to simulate a bytearray simple. (A bytearray is a
concatenated string of bytes), I do not use a mouse to type either, while it
is not imposible when I first draw a keybord on my screen.

OK, now that I understand, and disagree with completely. Passing around
an incomplete array, one whose length is not the same as the number of
valid entries, is a recipe for disaster. Sure, you'll remember what's
going on while you write this code, but six months later it's incredibly
easy to forget that you've got some other variable someplace telling you
what the "real length" of the array is.

Why just to disagree,? I real do not see the argument in this.

You will use a long, an integer, a double, a variable lenght string, however
a byte array of 400 bytes becomes to much for you?

Cor