Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Report Issue  RSS feed

 
Vu Pham
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I'm having an issue when creating Report with Java. When I create a report for about 5 months, the speed is very slow... I always wait at least 1 hour when creating a huge report like that. Do you know any solution that we can improve the speed? Thanks very much
 
Alonso Faust
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are a few different ways (assuming you're creating a report from a Database):
1. Optimize your code -- Optimization (depending on how non-optimized the code is) can increase speed incredibly. There are plenty of tutorials online about compiler optimization and simple code optimization. This however can only go so far.

2. a. Split Table into multiple related tables -- Depending on the information required in the report, you may be able to split the dataset and thus push less through the processor.
b. Combine multiple related tables into one -- Again depending on the information required, you may be able to make one(or two) table(s) of JUST the information needed and thus call your code less often.

3. Split reports across smaller intervals -- Large reports are generally going to take a long time. You may be able to compile a bunch of smaller reports to get the same result.

4. When all else fails and you simply just CANNOT wait for the code to come back, You could always get a faster computer. OR You could run the code across two computers: a client and a server. AS400's are databasing monsters and can turn out client-called MASSIVE reports rather quickly.

Hope this helped!
 
Joe Ess
Bartender
Posts: 9406
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alonso Faust:
You could always get a faster computer.


This is often a very cost effective solution. I've seen several organizations that had "server" machines that were actually old desktops that were replaced, shoved in a closet and dubbed "servers". Then they go on to complain how slow a program running on that machine is.
Step 0, which Alonso overlooked, is to identify the bottleneck. Premature optimization is the root of all evil (Knuth). If your database server's CPU is pegged at 100%, all the code optimization in the world will not make a difference. Run some benchmarks. Make a few changes. Run the benchmarks again. Repeat.
[ December 20, 2007: Message edited by: Joe Ess ]
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alonso Faust:
Optimization (depending on how non-optimized the code is) can increase speed incredibly


It can, but most non-focussed attempts at optimisation achieve no observable speed increase at all. All they do is make the code harder to understand.

As another poster has already said, you must identify where the bottlenecks in your system are, before attempting optimisation.

Optimisation is sometimes better directed at the overall architecture and design of the system than at small pieces of code - unless you really have proven that small piece of code is the main bottleneck.
 
Alonso Faust
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Chase:

It can, but most non-focussed attempts at optimisation achieve no observable speed increase at all. All they do is make the code harder to understand.


Yea, I think I misstated what I meant by "optimize your code". I was not talking about trying to use shorter, unintelligible variable names to try and pull out an extra couple bytes from the bytecode. I was referring more to unrolling small unnecessary loops that instantiate hundreds of variables when 1 would suffice, or whatever else you find massively memory intensive in your code. And as stated by a couple other posts, this should be done after identifying the code as the problem.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alonso Faust:
Yea, I think I misstated what I meant by "optimize your code". I was not talking about trying to use shorter, unintelligible variable names to try and pull out an extra couple bytes from the bytecode. I was referring more to unrolling small unnecessary loops that instantiate hundreds of variables when 1 would suffice, or whatever else you find massively memory intensive in your code. And as stated by a couple other posts, this should be done after identifying the code as the problem.


The length of variable names has no effect at all on Java performance. It's a compiled language. I suppose that the length of field names and method names does affect the class file size, but 99.9999% of the time, who cares?

Creating and destroying local variables has tiny cost in Java. You're only moving a stack pointer and setting a small initial value. It is much more important to stick to the "declare as close as possible to the use" principle.

Even creating and destroying objects on the heap is usually very cheap. Java is very, very good at allocating and deallocating short-lived objects. Only if their constructors are expensive to run would there be a noticable performance cost. Again, unless you can really prove there is something to gain, you should declare as close as possible to the use, rather than doing something else to chase illusory performance gains.
[ December 21, 2007: Message edited by: Peter Chase ]
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!