Hi Alan! Let me thank you again. The only question I have left is about this Win32 thing. Does that mean my dll will run @32 bits (or does it even matter)? thanx bigchump

Hi Alan! My o/s is Vista 64 Ultimate w/ 8 gigs mem. I have an identical machine (both are Velocity Micro hotrods) with Vista 32 Ultimate and 4 gigs. I also have two other machines with XP home. To load and display a 22meg file takes at least 17 seconds on the 32 bit puters and only 6.4 seconds on the 64. So, for my purposes 64 is much faster even though the 32 bit apps are written in C with some assy. and the 64 is written in C#. I have ported all my apps to 64 bit C# and all except the one in question have performance gains. Using binary serialization to write classes to disk causes the file to become 16x larger than it should be. I THINK YOU SOLVED MY PROBLEM: write a c++ dll to do file reads/writes. I've never written a dll so I'm sure I'll have some fun with that. I could use some tips on writing and calling a c++ dll from a C# program. Thanx again Alan! I would have never figured out the problem on my own.

Hi Simon! Yes, the file size is at least 16x larger than it should be! I am using binary serialization as far as I know. I already tried using char arrays (like the original app) instead of strings. That doesn't help at all. Here's the start of the code that writes the first small class: public void SerializeNow() { header c=new header(); Stream s=File.Open(@"C:\baduga\manure.tmp",FileMode.Append); BinaryFormatter b=new BinaryFormatter(); FileStream hread=new FileStream(@"c:\baduga\races.txt",FileMode.Open); //read races.txt StreamReader hread1=new StreamReader(hread); string temp; string[] t=new string[1435]; int a=0,x=0,y; while((temp=hread1.ReadLine())!=null) { if(temp.StartsWith("JJGENDRACE")) { c.entries=a; b.Serialize(s,c); for(y=0;y { b.Serialize(s,h[y]); } a=x=0; } else { t[x]=temp; if(t[x]=="") t[x]="0"; x++; if(x==1435) { if(a==0) { c.track=t[0]; c.date=t[1]; c.race=t[2]; c.distance=int.Parse(t[5].Trim('-')); c.distanceD=c.distance/220; c.surface=t[6]; c.type=t[8]; c.sex=t[9]; c.formtype=t[10]; c.purse=int.Parse(t[11]); c.purseD=c.purse/5000; if(c.purseD>50) c.purseD=50; c.claimprice=int.Parse(t[12]); c.trackrecord=float.Parse(t[14]); c.simulT=t[20]; c.simulR=t[21]; c.breed=t[22]; c.poly=t[24]; c.par2f=int.Parse(t[213]); c.par4f=int.Parse(t[214]); c.par6f=int.Parse(t[215]); c.parspeed=int.Parse(t[216]);

Baltoro wrote:

C# is almost identical to C++, except that C# is the official NET Framework language. Microsoft is trying to promote the NET Framework in a huge way, which is why you read that kind of thing (language of the future). And with programmers, the NET Framework is not very popular, for a number of reasons, speed being mentioned alot. The fundamental problem is that the NET Framework, still interops most of its functionality through the underlying Win32 APIs, and in the process, creates greater dependency, in addition to alot more conditional code jumps. Still, it's an improvement over COM in a number of aspects (like metadata uniquely identifying each assembly and type, garbage collection and memory allocation).

Thanx Baltoro for responding! I'll boil my problem down into a nutshell: With C/C++ writing a struct to file was easy. Now, I have to use "serialization" which causes datafiles to become HUGE with overblown overhead. My question is really simple: Can I use native c++ and compile to 64 bits???????? That would be a major fix if possible.... Thanx in advance bigchump

"If you posted the code that's loading the data from the binary file, it may be useful." Here's the code but the problem is not loading data but the SIZE of the file that is created. public void DeSerializeNow() { header c1=new header(); //change to header - horse - results horse[] c2=new horse[29]; Stream s=File.Open(@"C:\baduga\manure.tmp",FileMode.Open); BinaryFormatter b=new BinaryFormatter(); while(true) { try { c1=(header)b.Deserialize(s); label1.Text+=c1.track+" "+c1.poly+" "+c1.entries+" "+c1.par2f+" "+c1.par4f+" "+c1.par6f+" "+c1.parspeed+"\n"; for(int y=0;y<c1.entries;y++) { c2[y]=(horse)b.Deserialize(s); label1.Text+=c2[y].post+","; } label1.Text+="\n"; } catch { s.Close(); break; } } } Note the label stuff is just for debugging - it ain't used in real life... thanx bigchump

OK John, If you can make my 64bit C# app run faster than my c++ 32 bit one you can write your own ticket. LITERALLY-- bichump

Hi Carbon: "Going wrong with the C#. Nobody is disputing the performance of your other program. Sheesh." Brother, I think you're missing the point. When should a 32 bit app outperform a 64???????? Somethings gotta be wrong somewhere. Maybe my head's screwed on sideways. That's a possibility I don't discount. I PORTED ALL MY APPS TO C# AND ONLY ONE IS CAUSING THIS MISERY. When I say all, I mean over 14 different apps and only one doesn't work properly. Even the one with problems works OK just EXTREMELY SLOW. But slow is a killer in my business. What I need is a way to read/write structs/classes to file without the MAJOR OVERHEAD. sorry if I sounded hostile - I just need some help without any wisecracks.. bigchump

Hey Tom! Sure my 32 bit stuff is fine. Just like a Model T Ford. Sooner or later I will get beaten if I don't keep up. By the way, it ain't a "wonder program". It's the result of many years of very hard work. I read the King's English just fine but words like "extensibility" and "com object" are just jargon to me... If I were to say "Quitters stretching out with a big ML should be included in your exotics" is my jargon and may not mean a thing to you. The difference is -- I know when to use my jargon and when not to. When the title of the post has the word "amateur" in it - it might mean that someone doesn't understand the jargon. Of course, it is my choice whether to continue with C# or not. I was hoping for some help. I didn't get it. All I did was get chastised. Not one person explained to me why a 27mb file should become over 400mb. Not one. Oh, if you're wondering about my "wonder program" you can find it on TVG.COM under "TVG PICKS\Free Handicapping Info". So, C# and Bill Gates can go to the same place. I'll re-write in c++ much as I hate it. bigchump

Hi All! I have to write my own app to make a living. I am not an IT pro, or anything close to it. I do have a 32 bit app that is absoultely better than anyone else's. So I want to port my 32 bit app to 64 to stay ahead of the competition. So I go out and shell out big bucks for that 64 bit compiler. So I hear all this stuff about C# being the "language of the future". So I believe it. So I re-write the entire thing in C#. Now I have a 64 bit dog that runs 40% slower than my 32 bit app. Now I am pissed. So I go to the C# forums for some advice. No one helps. I get chastised. Now I have come to the conclusion that Bill Gates and all C# touts need their faces slapped. Rant Over bigchump edit: some expletives were "deleted".

modified on Thursday, June 12, 2008 5:20 PM

Hi Carbon: "It'll be nigh on impossible to tell where you're going wrong here." Going wrong? I don't think so. My 32 bit app beats everything else out there. The problem is it's written in c/c++ with some assy. that doesn't compile with VS8. So I re-wrote the entire thing in C#. Now I've got a 64 bit dog. That's all I know. I never liked c++ and hate to use it but I'm becoming desperate and need some advice in the King's ENGLISH I can understand. I read that thing ("have a look at this") and hardly understood a word of it. My app is really simple. Read a few struct/class from disk and run about 3000 "if" statements on it and come up with an answer. thanx for any help bigchump

Hi Christian!

Christian Graus wrote:

bigchump wrote: My database is over 20 years old and grows by about 512K every day. Oh, a custom format ? Yes, a relatively small file on HD is indexed to database on tape drives to find records that match. bigchump wrote: I don't know anything about SQL except that I run circles around people who do use it. Well, if you're not using SQL, you're using some specialised code written for your purpose, no surprise it may work faster than a more generalised approach ( but still impressive ) There's no comparison to SQL. I wrote all the code many years ago before SQL even existed. bigchump wrote: What I don't understand AT ALL is the inability to read/write a struct/class directly to disk without a whole lot of overhead involved. Well, did C++ just write a class for you ? You can store a class the same as you did in C++, by writing code to stream the component parts, if you like. Serialisation actually works mostly for free, if you're only using simple types that know how to serialise themselves. IF I UNDERSTAND YOU, COMPONENT PARTS MEANS WRITING ONE ITEM AT A TIME TO A BINARY FILE. The problem with that is one of these classes has over 1500 different items. That would mean writing 1500 lines of code to write and another 1500 to read???? bigchump wrote: I don't understand why the JIT compiler "chokes" (only at 64 bit, not at 32) the first time a large function is called. Because it's compiling it. Why is your function so large ? What do you mean by 'chokes' ? I tried breaking it down into several smaller functions. It just ran slower. "Chokes" means serious delay. Why does it choke at only 64 bits and not at 32?????? bigchump wrote: It's also likely that I've got my head screwed on backwards and am missing something simple. I suspect that I'm not fully understanding you just yet

That's because I'm not a programmer by profession. It took me a while to figure out what "component parts" meant.

Thanks Christian! My database is over 20 years old and grows by about 512K every day. I don't know anything about SQL except that I run circles around people who do use it. My compiler is set to "any CPU" on my 64 bit machine. I understand all that stuff. What I don't understand AT ALL is the inability to read/write a struct/class directly to disk without a whole lot of overhead involved. I only get paid if I am the first one with the answer, therefore speed is critical. From my perspective, this whole DOT NET thing is a throwback to the old "interpeter" days with this JIT thing. I don't understand why the JIT compiler "chokes" (only at 64 bit, not at 32) the first time a large function is called. I can write a native console app to retrive the data and write a small temp file that a C# app can then read. The problem with that is the original 32 bit app is still faster and there's every indication that the native app is running @ 32 bits. It's also likely that I've got my head screwed on backwards and am missing something simple. thanx bigchump

<blockquote class="FQ"><div class="FQA">Christian Graus wrote:</div>One has to ask if you're porting to C#, or if you're just lost ?</blockquote> I've ported everything to C# and am generally pleased. My business requires me to write my own programs. I've been doing it for over 20 years using C and assy. But I'm not any kind of expert and need some answers in plain English. The help screens in VS8pro are virtually worthless to me. I don't understand the jargon AT ALL. Never liked C++ and don't want to use it *IF* I don't have to... It's really annoying to have my 32 bit machine run circles around my 64 bit stuff. So back to my question, is it possible to create a custom database with C# that is compact and runs fast? thanx bigchump

Hi All! I've been trying to port my apps from VS6 to 64 bit. When I use serialization to write classes to fie - what should be a 27mb data file becomes 459mb! And it runs S-L-O-W. There are no methods (functions) in the classes. Just data. The data file was created the (EASY) old way by writing structs to a binary file. I also tried that "marshall" thing - what a joke! So, my question is how in the world do you write structs or classes to a file without tons of overhead? I know I can use C++ native code but surely there must be a better way. If not, can native code be compiled to 64 bit? thanx for any responses bigchump