|
|
|
 |
Crazy ass question If you want to achieve absolute speed and size is it reasonable to write your UI components in Win32 assembler? Where I work we use DBArtisan to manage our databases. The problem is, when queries get really big, the app starts to drag and responds very slowly. If the developers used Assembler instead of Delphi, would it be fast and light?
Paint in Black
If your programmers wrote everything in Assembler your company would probably run out of money before the next release.
Stephen Jones
The problem is not actually the DB itself. I'm talking about the sheer number of records returned being so big the app becomes unresponsive.
Paint in Black
I had the S&M inclinations to look at the codegen and I can tell you it's wonderfully optimized. But even that is completely besides the point.
Alex
Then why is the app so damn slow?
Paint in Black
If your app is dragging because you're giving it too many records from your DB, then don't give it so many records. I can't give any specific advice since I don't know anything about your app, but there are lots of ways to efficiently present large amounts of data.
Brad
We use a commercial app, DB Artisan. It seems to have been made in Delphi and since it's a DB administration tool, I thought it was suppose to be able to handle very very very large amounts of data. It's not suppose to feel heavy...
Paint in Black
Could simply be the hardware. What kind of app is it? If it's a data mining app then you should consider denormalization.
Stephen Jones
I think you are probably getting more data than can fit in the ram of your workstation. As a result, windows begins to swap it out to the harddrive. It probably has nothing to do with the program at all.
Eric Debois
How much would it cost to add a couple Gig of RAM compared to rewriting one query? Probably not even close.
Anony Coward
If you UI is dragging while you try to process large amounts of data, have you tried running the data processing in a separate thread? I'm not familiar with your development environment, but in Swing that is what I do to keep the UI responsive while processing a lot of data.
name withheld out of cowardice
"How much would it cost to add a couple Gig of RAM compared to rewriting one query? Probably not even close."
.net, the equivalent of MS Bob.
You need to profile your code figure out really where the slowdown is. My guess is that you suspect the Windows display because it is taking forever to load some type of list- which makes the obvious- the more records you try to prefill a list with the longer its going to take. If this is the case- do you really need to fill a list with thousands of records when the user is only going to be able to look at say 20 at a time?? Come up with some sort of "Virtual List" type solution. How responsive is the query (does it take more time to get back the reults/recordset than fill the list)? You need this data to make an informed descision (not to be too blunt- but assembly is not the informed decision and it is a crazy ass question). Re-evaluate the 3rd party tool your using- just because you bought it doesnt mean it is 'industrial' or good for that matter...
MikeG
Are you trying to display a few million entries in a listbox or grid? If so, what use is that?
Just me (Sir to you)
Listen, I did write the damn thing. My company just bought it and I just run queries against it. Those queries are always on the heavy side, and having some theoretical knowledge of SW development (PHP...) and having heard that Assembly is smaller and runs faster than anything else, I decided to ask you guys how to do this.
Paint in Black
"...sheer number of records returned..."
Torque
Paint in Black may forget, but I hear you. The strength of this forum is precisely these gems like yours. Can you explain why I mustn't exceed a list box in the amount of data?
RP
Pretty much the only time you need to concern yourself with rewriting code in assembler is after you've improved your algorithms as much as possible with higher level languages. At that point, use a profiler and see where it's spending the most time. That's the part to rewrite in assembler. There is no point in rewriting the whole thing.
Aaron F Stanton
To answer the original question, DBArtisan is slow with tons of data because it wasn't designed to be used with tons of data. It has nothing to do with the implementation language - if they'd used assembler and attacked the problem in the same way, you'd see roughly the same performance. If they wrote it in Delphi and attacked the problem differently (that is, designed the program to be good at browsing large amounts of data), you'd see far better performance.
schmoe
Tell the developers to find all the places where they multiply by 2 and use this assmebly code instead:
Billy Joel on Software
That assembler development is so expensive is a myth. With a decent macro assembler it's quite efficient. Main problem is documenting your code, there's not really any "idioms" (don't know if that's the right word) as other languages have, so you kind of make up as you go.
Jonas B.
What MikeG refers to above is often called "paging" -- ie, you load 50 records at a time into the UI and have previous/next buttons, rather than 200,000 records all at once. This is easy enough to accomplish in the data tier by adding a row count column to the query (or an autonumber to the table) and filtering the results on it.
Joe
"Can you explain why I mustn't exceed a list box in the amount of data?"
Torque
What does all this have to do with asses? Maybe I misunderstood the question...
5v3n
Is it the retrieval that is slow or the display?
Billy Boy
"and having some theoretical knowledge of SW development (PHP...) :
Mr. Analogy
What everyone else said... a database application is almost always an "I/O bound" situation, meaning that the physical process of input/output is an order of magnitude slower than the code running on the client workstation's processor. Think about all the crap that has to happen to communicate the data back to the workstation: even a fast ethernet will be much slower than memory to memory copy. And you're dependent first of all on the network speed.
Bored Bystander
Assembler != Silver Bullet
Bill Rushmore
"and having some theoretical knowledge of SW development "
free(malloc(-1))
Hey, come on. I've been doing a bit of everything in IT, from PHP websites to help-desk. Having heard that assembler produced smaller and faster code (I have written this somewhere before) I asked the theoretical question of whether it would be better to write the UI in assembler.
Paint in Black
The answer to your question is NO.
Bob
Last time I had optimizers and assembly in the same task, I was getting RID of the assembly in favor of C so I could rewrite the algorithm easier. Worked great, ended up 300x faster. How? Mostly through not running code at all - caching approximate values instead of recalculating them for example. That's the theme here: Use a profiler, don't do slow things, do necessary slow things less often, and finally optimize the most frequent code path. Not a silver bullet, but it helps.
Mikayla
I would write assembler code that allocates a crap load of ram and runs very slow. Your problem has nothing to do with the language.
christopher baus.net
If you are doing a file extract (creating a file of data for some other purpose) DB Artisan may not be the best tool. It has to format the data for display etc. It might be faster to use a simplier program that will run the sql and create an output file, like SQL Plus (oracle) or isql (MS or Sybase).
John
Wordperfect was written in assembly, and was slow as a dog.
Big B
Having compiled Word Perfect a few times, I think I can safely say that not all of Word Perfect was written Assembly. In fact a very small amount of it was.
christopher baus.net
"Wordperfect was written in assembly, and was slow as a dog."
Former WP developer
Damn straight, whigga! <jk>
Crazy Ass Whigga
|
