[Bug 61722] New: Review ways to avoid new Integer()/Integer.valueOf() in performance sensitive places

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 61722] New: Review ways to avoid new Integer()/Integer.valueOf() in performance sensitive places

Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=61722

            Bug ID: 61722
           Summary: Review ways to avoid new Integer()/Integer.valueOf()
                    in performance sensitive places
           Product: POI
           Version: 4.0-dev
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: XSSF
          Assignee: [hidden email]
          Reporter: [hidden email]
  Target Milestone: ---

We did some changes in bug #57840 to use "new Integer()" instead of
"Integer.valueOf()", because the caching for reduced memory use in "valueOf()"
comes with a slight CPU penalty, see r1747837.

However later on, these were reverted again as some code cleanup tools flag
these as "sub-optimal" and suggest to change them to "valueOf()".

Before re-applying this again, let's do some research if there are better ways
to do this as it seems we create lots of objects, mostly to look up values in
maps.

Maybe we should use something like Trove Maps which allows to use primitives in
maps directly without the cost of converting to objects, see
https://bitbucket.org/trove4j/trove for details.

See the performance test added in r1747878 for a starting point of an
evaluation of the effect of changes.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Bug 61722] Review ways to avoid new Integer()/Integer.valueOf() in performance sensitive places

Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=61722

Dominik Stadler <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |57840


Referenced Bugs:

https://bz.apache.org/bugzilla/show_bug.cgi?id=57840
[Bug 57840] [PATCH]  Support for structured references with Excel tables.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Bug 61722] Review ways to avoid new Integer()/Integer.valueOf() in performance sensitive places

Bugzilla from bugzilla@apache.org
In reply to this post by Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=61722

--- Comment #1 from Greg Woolsey <[hidden email]> ---
This article[1] has an interesting set of tests, results, and summary info for
multiple primitive collections frameworks, including Trove.

Most interesting points to me:
 * Trove isn't under active development, and hasn't been for a few years.  It
was also slowest.
 * Fastutil is the overall winner for performance, although memory wasn't a
consideration in these tests.
 * Fastutil is a 28M JAR file (!)

If we are only interested in Map<int, ? extends Object> type maps, perhaps a
slimmed-down version of a stable build of Fastutil could be used.  It appears
license compatible, and we could investigate an AutoJar or similar step added
to the build to create an artifact bundled/released with POI.

[1]
http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Bug 61722] Review ways to avoid new Integer()/Integer.valueOf() in performance sensitive places

Bugzilla from bugzilla@apache.org
In reply to this post by Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=61722

--- Comment #2 from Dominik Stadler <[hidden email]> ---
FYI, some quick and dirty test with the file from bug #57840, not
representative as not done in clean environment:
* Origin: 3m35s
* With new Integer(): 3m22s
* With Trove and new Integer(): 2m28s

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]