|
Good point, I'd rather do:
for (int i = 0; i < times % 8; i++)
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Hi,
if it is a byte, then it is modulo 8 you want.
IMO, assuming you need a lot of those, the fastest implementation for byte data is
using a two-dimensional array, properly initialized.
byteShifter[shiftAmount%8][value];
Of course you could store all kinds of 2-operand functions in such a table,
not just rotates.
For larger data items, this approach is becoming memory costly.
FYI: with C# modulo may yield negative values for negative inputs, you may have
to correct for that.
|
|
|
|
|
Ew, not loops.
public static byte
RightRotate
(
byte value
,
byte times
)
{
times %= 8 ;
return ( (byte) ( value >> times | value << 8-times ) ) ;
}
public static byte
LeftRotate
(
byte value
,
byte times
)
{
times %= 8 ;
return ( (byte) ( value << times | value >> 8-times ) ) ;
}
But as Luc says... table lookup.
|
|
|
|
|
PIEBALDconsult wrote: But as Luc says... table lookup.
Would that really be faster?
It looks to me like validating the indexes and calculating the offset in the array data would be about as much work as just calculating the value.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
|
I don't think << is circular but I do believe there is an opcode which is which would mean C++ and not C#
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
True, << and >> means Left Shift and Right Shift.
But when done in a specific way, it can be "tricked" to do Circular shifts. 
It is said that the most complex structures built by mankind are software systems. This is not generally appreciated because most people cannot see them. Maybe that's a good thing because if we saw them as buildings, we'd deem many of them unsafe.
|
|
|
|
|
Hi,
Problem:
I have a VS2005 C# Application that uses a third party managed dll which needs a second unmanaged dll.
I added the managed dll to my projects references, and so it is copied to my application path automatically after build. But what about the unmanaged dll?
How to copy it automatically? In C++/CLI you can set "copy local dependencies" and all dependencies are copied automatically.
But in c# I found nothing like that?
Any Ideas? Thanks for any help!
|
|
|
|
|
Don't know if there's an automatism for this in Visual Studio. I usually put the unmanaged dll into the project folder and copy it with the post-build event command line:
copy "$(ProjectDir)unmanaged.dll" "$(TargetDir)\unmanaged.dll"
|
|
|
|
|
that was also my first idea.
but I don't want to copy to the targetdir of the project, but to the output path of the whole solution ... since my project is used in other projects and solution dir's may vary.
so I tried something like that:
copy "$(ProjectDir)unmanaged.dll" "$(SolutionDir)\$(SolutionName)\unmanaged.dll"
Problem is, SolutionDir is not the OutputPath and there's no macro that defines the output path!?
Of course I can use "$(SolutionDir)\$(SolutionName)\$(OutDir) ... but this works only if Solution and the Project are build with same settings.
But why is there no macro for the Solution output path!?
By the way, the second proposal just works fine.
|
|
|
|
|
By the way, the second proposal just works fine.
Yes, I know. Just didn't think of it cause I always copy things to TargetDir. This is because we often use a kind of plug in technique: application reads from configuration from which dll to load the controls, so we don't have a reference to the controls dll and the application won't find it when started from VS, unless we copy it to the folder where the exe ist started.
|
|
|
|
|
AFAIK there should be a "Copy to Output Dir" property. Select the component in solution explorer and check the properties. There you can set
Build Action -> Component
Copy to output Dir -> Copy Always/Copy if newer
*jaans
|
|
|
|
|
Hi,
I have encountered a very strange problem.
I have a stuct that has a string variable inside.
I'm creating a list of the Struct's type, and try to assign the string variable.
this doesn't work !!!
but If I create a Class instead of a struct this work!!
The Struct:
public struct Struct1
{
private string s;
public Struct1(string d)
{
s = "";
}
public void SetS(string i) { s = i; }
public string GetS() { return s; }
}
The Class:
class myStr
{
private string s;
public myStr(){}
public void SetS(string i) { s = i; }
public string GetS() { return s; }
}
The Main:
static void Main(string[] args)
{
List<Struct1> ls = new List<Struct1>();
Struct1 str = new Struct1("f");
ls.Add(str);
ls[0].SetS("hi");
string mys = ls[0].GetS();
Console.WriteLine("mys: " + mys);
List<myStr> ls2 = new List<myStr>();
myStr str2 = new myStr();
ls2.Add(str2);
ls2[0].SetS("hello");
string mys2 = ls2[0].GetS();
Console.WriteLine("mys2: " + mys2);
}
The output is:
mys:
mys2: hello
this seems very strange!
I would be very happy if someone has an explanation.
Thanks.
|
|
|
|
|
lune12 wrote: this seems very strange!
No, the behaviour is perfectly correct.
lune12 wrote: I would be very happy if someone has an explanation.
Read up on the differences between value and reference types.
|
|
|
|
|
leppie's is correct.
In case of a struct the operation ls[0] will return a copy of the struct that's inside the list, so assigning a value to it and then discarding it (by letting it get out of scope) will have no effect.
In contrast, in case of a class the operation ls[0] will return a reference to the object in the list, so assigning a different value to it is possible.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
In addition to what has already been said:
Mutable structs (ones where you can change the members) should generally be avoided, for just the reason that you have experienced. If you make the struct immutable, it would work, as then you would have to create a new instance to get one with a different value:
public struct Struct1 {
private string _s;
public Struct1(string d) {
_s = d;
}
public string S { get { return _s; } }
}
static void Main(string[] args) {
List<struct1> ls = new List<struct1>();
Struct1 str = new Struct1("f");
ls.Add(str);
ls[0] = new Struct1("hi");
string mys = ls[0].S;
Console.WriteLine("mys: " + mys);
}</struct1></struct1>
Structs are tricker to implement correctly than classes, so unless you really need a struct, just stick with classes.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Hi,
Thanks all!
So when the Struct is really needed?
Do they are special case that a struct is better than a class?
thanks.
|
|
|
|
|
Hi is there a way to kill a byte array. I am loading images from a file and to instantiate an image class with the data I have to convert my string to a byte array and then stick that into a memory stream and then get the image from that. But my byte arrays are always sticking even after I null and clear them. (According to ANTS memory profiler) I tried forcing the GC to collect the memory and it is still not clearing. The problem is with large files with many images. These arrays take upto 1 gb of ram.
This is the code. Any tips or ways I can fix this problem.
if (mChildNode.FirstChild.Value != string.Empty)
{
byte[] byteData = System.Convert.FromBase64String(mChildNode.FirstChild.Value);
MemoryStream stream = new MemoryStream(byteData);
mImage = new Bitmap(stream);
stream.Close();
stream.Dispose();
stream = null;
Array.Clear(byteData, 0, byteData.Length);
byteData = null;
mChildNode.FirstChild.Value = "";
mChildNode.FirstChild.Value = null;
}
|
|
|
|
|
Hi,
your code contains a lot of unnecessary stuff, e.g. there is no reason whatsoever
to clear the array you are no longer interested in. If byteData is the only reference
to the array, it will be collectable as soon as byteData either goes out of scope,
or is modified (e.g. set to null). The array content does not matter in this.
But collectable does not mean collected; the Garbage Collector will collect only
when it feels a need to do so, which typically means something else is being created,
needing some memory, and the GC decides it would be either necessary or desirable
to go look for freeing some memory first.
For regular objects, the GC moves them together to avoid wasting memory holes
(fragmentation). So debug tools will pretty soon be unable to read the old data,
since it gets overwritten by the data of the new object that caused the GC to
kick in in the first place.
Now large objects are treated differently; there is a special "large object heap",
where objects never get moved around to keep free memory logically contiguous, mainly
because it is too expensive to move them. IIRC the threshold once was around 80KB.
So even when a large object gets collected, as long as a new large object is not
overwriting the old one, your debug tools will be able to see the old content in memory.
A terrible drawback of all this is when your large objects require an ever growing
size, the holes never get reused, fragmentation kicks in, and you eventually run
out of memory, although most of the large object heap may be free!
If this is not acceptable (your app needs to run for long times) and/or if your
problems persist, I would recommend you try and avoid those large objects altogether,
e.g.:
- why store multiple images in a single huge file? consider using one file per image,
and one file with filenames.
- why convert a very large image to a single base64 string? consider using several
smaller base64 strings.
etc.
Of course, dealing with the above will require more code, but in the end it
will be worth it and perform much better.
|
|
|
|
|
-The issue is that this application uses xml files which contain all binary wave and image data... which is where the mChildNode comes from. Management is requiring the use of a single xml file that contains all the data.
-Is there a faster, more performant way of grabbing these images from the xml file. Is it possible to convert the xml node value to several smaller strings and then combine them later on?
|
|
|
|
|
What is the size of a single wave/image?
Are you sure you want all the waves/images at the same time? You can't display them
all at once, can you? How about using thumbnails (best also stored in the same XML file)?
If your individual objects are huge, then there are for sure ways to get at them
even under memory constraints, and faster than in a straightforward manner;
my approach would consist of:
- storing smaller parts of the image instead of the whole thing, even in the XML file;
- retrieving the data using multiple threads, into a huge bitmap that got pinned down,
making say 4 threads each responsible for a quarter of the bitmap.
You might want to reveal more of the context...
|
|
|
|
|
Yes, the application could potentially display an unlimited number of images at the same time. The size of each image is possibly around 200*200 could be less and could be more.
I am already using threads to parse the xml file concurrently. My xml parser is recursive...
The only issue is the remaining byte arrays that have a large impact on a mobile device that is also being targeted.
|
|
|
|
|
OK,
Justin Time wrote: on a mobile device that is also being targeted.
that is new information.
Justin Time wrote: The size of each image is possibly around 200*200
That is not what I call a large image. It would take less than 200KB.
Justin Time wrote: Yes, the application could potentially display an unlimited number of images at the same time.
So it is a server with an unlimited number of clients? or a client with an unlimited
screen? 
I am performing some memory tests on a Vista laptop.
So far it confirms the large heap theory, the 80KB threshold, and the risk for
fragmentation.
Preliminary recommendation: try to keep your objects smaller than 80KB, as much
as possible.
There may be article material in here.
More research is needed tho.
I don't have a CF device available, and have never accessed one, so I have
no idea how much worse it might be.
|
|
|
|
|
Images are resized to fit the screen... = unlimited (marketing).
So essentially this is a hope and pray game? Hope that the gc on the device would collect the unused byte arrays?
|
|
|
|
|
In the mean time I have read a dozen articles on the subject.
This is my conclusion:
1) objects smaller than 80KB will pose no problems if handled correctly.
2) objects larger than 80KB are allocated in LOH (Large Object Heap) which is
susceptible to fragmentation since there is no compaction for it; there are some
guidelines to reduce the likelyhood (i.e. postpone the unfortunate situation), see e.g.
Nish's article[^].
My advice is avoid unnecessary large objects (i.e. >80KB), so don't turn an image
into a byte[] or a string that exceeds that threshold.
BTW In software hope and pray is not a viable strategy.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
