10

I m working on a system which get thousands of requests per second, and essentially one of the tasks we are trying to avoid is to create unnecessary/extra objects.

We need to validate incoming request for 6 request items per se.

I m thinking of creating a class per each item validation.

However, I m trying to justify if i should use static validation classes vs object with instances that contains HttpRequest as the instance field.

should i use static classes or objects? what would you do?

Essentially, what I m doing is injecting List<IValidator> validators to request handler and iterating over it. but not sure if i should have an instance vs static classes.

DarthVader
  • 52,984
  • 76
  • 209
  • 300
  • What pros / purposes would having an instance serve, IMHO to me this problem would fit a static design quite well. – JonH Aug 28 '12 at 18:08
  • an instance with a field would have a state therefore easy for testing. Static classes dont have states. – DarthVader Aug 28 '12 at 18:08
  • 2
    Right but in your example is this state necessary? – JonH Aug 28 '12 at 18:09
  • Well not sure, we are doing TDD so testing is crucial. But we also need performance. – DarthVader Aug 28 '12 at 18:10
  • Why not just inject the same instances over and over again? – Sign Aug 28 '12 at 18:11
  • Well then you ll have Thread Safety problems no? We are not using any DI container but we have a kinda Service locator container that was developed in house. and not allowed to bring in any package from outside. – DarthVader Aug 28 '12 at 18:12
  • You can make your Validators stateless and pass in the request. Then you can use them concurrently with no problems. – jeff Aug 28 '12 at 18:12
  • @jeff how do you justify that to team ? – DarthVader Aug 28 '12 at 18:13
  • 2
    You seem to have answered your own question in that your requirement to have stateful validators indicates making new validator objects is the right approach? Modern JVM is really rather good at churning through short lived objects. – Affe Aug 28 '12 at 18:18
  • 2
    @DarthVader Well, that buys you not using statics, so testing, mocking, etc. will be easier. It also only requires one of each type to be instantiated, so no big memory consumption. – jeff Aug 28 '12 at 18:18
  • 1
    @jeff it adds up when u get thousands of request per second. – DarthVader Aug 28 '12 at 18:25
  • @DarthVader what adds up? You can't change the fact that you get that many requests. But you can change how many objects you need to service them. If you create stateless validators then you can service all requests with the same set of validator objects. – jeff Aug 28 '12 at 18:26

2 Answers2

9

Have you actually measured the impact creating new Validator instances has on memory versus re-using static methods? The cost of using a short-lived object is very, very small. You should measure what the difference between the two approaches is and if there is no measurable difference, use the one where the code is cleaner and easier to understand.

In cases like this it always makes sense to measure the difference instead of just assuming one versus the other is better.

matt b
  • 138,234
  • 66
  • 282
  • 345
  • well there is L&B team that measures it and last time they came back with a result saying we have too many objects. – DarthVader Aug 28 '12 at 18:37
  • "too many" compared to what? Was the same application measured using static methods instead of the short-lived objects? At the risk of making a snap judgment, "too many objects" itself sounds like a snap judgment. – matt b Aug 28 '12 at 18:39
  • 2
    There are lots of reasons for having "too many objects". The most common by far is in string parsing. – Hot Licks Aug 28 '12 at 18:39
  • 2
    The only true way to know which approach is more performant and has a lower GC impact in your application is to benchmark and measure both variations *in your application*. With this type of thing it can be dangerous to just take accepted wisdom and apply it to your unique situation. Especially considering that the cost of allocating and garbaging collecting short-lived objects is frequently overestimated. – matt b Aug 28 '12 at 18:40
  • 2
    If you have the time to watch it, this is a good presentation on JVM performance and GC tuning from a developer at Twitter, where they have had lots of practice: http://www.infoq.com/presentations/JVM-Performance-Tuning-twitter – matt b Aug 28 '12 at 18:40
  • Very inspiring. Thank you very much! – 尤川豪 Nov 07 '14 at 00:27
  • If the short-lived object is part of a long-lived class, you could use singletons to make sure that only one object exists at a time. – d00d Oct 20 '22 at 06:56
1

In multithreaded environments, using static classes / methods always open concurrency pitfalls. Since the creation and collection of short lived objects is cheap, it is often better to create short lived objects than running into cuncurrency issues and extra synchronization, which is expensive.

Struts switched from static request handlers to instance-based request handlers for similar reasons.

Sylar
  • 2,273
  • 2
  • 18
  • 26
  • 2
    Concurrency issues seems to happen only when you modify static variables: https://stackoverflow.com/questions/14126556/concurrent-access-to-static-methods –  Jun 05 '17 at 19:38