Win a copy of Fixing your Scrum this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

using Calendar

 
Ranch Hand
Posts: 4716
9
Scala Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i just finished a clock program but one thing bothers me. i get the time like this:

this creates a new instance of calendar every second. it doesn't seem right creating so many objects, but the examples i found by googling do it the same way.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Randall Twede wrote:this creates a new instance of calendar every second. it doesn't seem right creating so many objects, but the examples i found by googling do it the same way.


You could have a look at Calendar.add(). However, there may be other reasons for creating individual objects that I'm not aware of from your description.

Winston
 
Randall Twede
Ranch Hand
Posts: 4716
9
Scala Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i think i will try that. i need something to do until i can think of a new project anyway.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Creating a Calendar object every second is no problem at all for the JVM. There's no reason to worry about this being somehow slow or inefficient.
 
Randall Twede
Ranch Hand
Posts: 4716
9
Scala Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well i just didn't like the idea of throwing them all on the heap.
i tried this

but it added 2 minutes every time the second hand hit zero. obviously the Calendar class changes the minute if adding to second puts it over 59.
the correct code is simplicity itself:

so now i only create one calendar when the program first starts. much better IMO
we shouldn't depend on gc() so much
 
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But that relies on your getTime method being called at exactly one second intervals. Unless your program and the computer it is running on is doing absolutely nothing else, it wont take long for your program to become inaccurate. If you really are worried about all those Calendar objects being created (and there is no need to be) then you should at least reset your now variable at regular intervals.
 
Marshal
Posts: 22385
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Randall Twede wrote:obviously the Calendar class changes the minute if adding to second puts it over 59.


Correct. If you don't want this there's also the roll method, but I've never used that before myself.
 
Randall Twede
Ranch Hand
Posts: 4716
9
Scala Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
rob, but that is exactly what i wanted.
joanne, i trust the Timer class to be accurate. and i don't think the multi-processing environment will matter.
in c or c++ the original code would have resulted in a "memory leak". i haven't used c++ much, but i do know that in java, even calling gc() from your code doesn't ensure it will run. anyway, i think the new code is better
and only one line more
 
Ranch Hand
Posts: 479
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with the post that opined that the Timer is going to get inaccurate over time.

You might consider having another timer wake you up every minute or 5 or whatever and correcting the time on your clock with the system clock, though I think the original method is the correct one. This seems to me a case of attempting optimization where none is required. You're (evidently) going to create 2400 objects an hour, no reason to think they are large or difficult to create. It just doesn't seem to me a big enough problem to solve with something that risks getting your clock out of sync with the system clock. Do you know how many objects are created during the .add() method? No? Neither do I...

rc
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Randall Twede wrote:well i just didn't like the idea of throwing them all on the heap.
...
we shouldn't depend on gc() so much


If the Calendar object you're creating is only accessed through a local variable inside the method, like this:

then the JVM will be smart enough to allocate it on the stack instead of the heap (escape analysis), and the garbage collector will never have to deal with it (freeing memory from the stack has zero cost - it will automatically be freed when the method returns).

The JVM really does many more very sophisticated optimizations than you think. Trying to optimize your code solely based on having a vague feeling that something is inefficient, is ineffective. It's much more important to write clear and understandable code than to jump through all kinds of complicated hoops for something that you don't have any evidence for that it's really a performance problem.

If you need to optimize code, then let yourself be guided by real evidence: use a profiler to measure the behaviour of your program, and do something about the bottlenecks that you discover that way.
 
Ranch Hand
Posts: 73
Android Netbeans IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Randall Twede,

If you are skeptical about Calendar instance, there is another way to make sure you create only one instance and use the same for every second
Make the 'now' variable static and class level and change the getTime() to something like


 
Randall Twede
Ranch Hand
Posts: 4716
9
Scala Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
after thinking about it i agree with joanne that the clock will run slow over enough time. that is probably why the examples i found did it the first way. thanks jesper for the excellent advice. i will do it that way(the local variable thing).
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Randall Twede wrote:after thinking about it i agree with joanne that the clock will run slow over enough time.


Well actually, after reading the Javadoc for Timer, I had sort of accepted your argument. The Timer class will call your method once for every second that passes - there's just no guarantee that these calls will be at one second intervals. So I think your clock would be accurate but may appear a bit jerky if there is ever any delay. But I think this would be the case however you implement your getTime method.
On a more general note however, Jesper's advice is correct. Don't worry about garbage collection unless you can show that it is causing a problem - a lot of time has been spent implementing those algorithms to make them as efficient and unobtrusive as possible.
 
I claim this furniture in the name of The Ottoman Empire! You can keep this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic