Re: [JPP-Devel] starter script
On 01.10.2013 22:09, Michaël Michaud wrote: Hi Ede, A few days ago, I ran OpenJUMP on a windows server with 16G RAM, and I noticed that it gave nearly 16G to the JVM (I first thought it gave even more as it showed 17 000 000 000 bytes). In the script you wrote : use 100% of ram as default limit (1.124 is a factor to make java64 really use that much) Don't understand 1.124, but it seems you really give the maximum possible memory to the process. for some reason java does not interpret values literally when assigned via -Xmx, but always some percentage less. Can you explain a bit more. Giving 100% ram seems excessive. Moreover, I thing that the ram allocated with -xmx excludes the one used by the system to run the jvm itself. -Xmx is a soft limit telling jre never to use more than that. you can actually set -Xmx to bigger values than ram (incl. page file size) w/o a problem. when there is no memory to reserve anymore jre will throw heap space error anyway. rationale is that desktop software should all memory available. ..ede -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Default Type for bigint
Hi, in com.vividsolutions.jump.datastore.jdbc.ValueConverterFactory Currently the bigint in database table is transcribed into a String object type. But the default type of aggregation is also bigint. for example: SELECT code_departement, count (*) as nb FROM anyTable GROUP BY 1 nb has bigint! I think we should change the type attribute has AttributType.Object to AttributType.INTERGER What is your opinion on the subject? regards Eric -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Default Type for bigint
Hi Eric, Nice to see you still use OpenJUMP ;-) Currently, I'm not in favour of this change and have a few reasons : I'm working on a new postgis driver where I need to manage database identifiers. Often, database identifiers use bigint (from sequence). bigint are naturally converted to java long and I choose to encapsulate it into an Object (it has been converted to a String until september 2013). Casting a bigint to an int does not seem safe enough to me. For a count operation, it is ok as we rarely manage more than 1M features in OJ, but for identifiers, it would be really unsafe. Moreover, it is quite easy to cast count() to int explicitely with for example SELECT code, count (*)::integer as nb FROM anyTable GROUP BY 1 I have also tested to cast AttributeType.OBJECT to AttributeType.INTEGER afterwards in the schema editor, and it seems to work well. Other opinions ? Michaël Hi, in com.vividsolutions.jump.datastore.jdbc.ValueConverterFactory Currently the bigint in database table is transcribed into a String object type. But the default type of aggregation is also bigint. for example: SELECT code_departement, count (*) as nb FROM anyTable GROUP BY 1 nb has bigint! I think we should change the type attribute has AttributType.Object to AttributType.INTERGER What is your opinion on the subject? regards Eric -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Default Type for bigint
Hi Michaël Yes i always uses OpenJump. And I tried to do accept as GIS tools by my society (a big europeen insurance society). If I resume the situation: handle identifier( sequence) by integers is not sure ( I don't understand why, but I trust you ) but for others values is preferable because requests are less long to write. PostgreSQL jdbc implementation can't retrive key or primary key information about table? Handle sequence with object and other bigint with integer. An other subject can I help you on the new postgis driver? Do you have a road map? Kinds regards Eric Lemesre (de mon Androïde) Le 2 oct. 2013 22:24, Michaël Michaud michael.mich...@free.fr a écrit : Hi Eric, Nice to see you still use OpenJUMP ;-) Currently, I'm not in favour of this change and have a few reasons : I'm working on a new postgis driver where I need to manage database identifiers. Often, database identifiers use bigint (from sequence). bigint are naturally converted to java long and I choose to encapsulate it into an Object (it has been converted to a String until september 2013). Casting a bigint to an int does not seem safe enough to me. For a count operation, it is ok as we rarely manage more than 1M features in OJ, but for identifiers, it would be really unsafe. Moreover, it is quite easy to cast count() to int explicitely with for example SELECT code, count (*)::integer as nb FROM anyTable GROUP BY 1 I have also tested to cast AttributeType.OBJECT to AttributeType.INTEGER afterwards in the schema editor, and it seems to work well. Other opinions ? Michaël Hi, in com.vividsolutions.jump.datastore.jdbc.ValueConverterFactory Currently the bigint in database table is transcribed into a String object type. But the default type of aggregation is also bigint. for example: SELECT code_departement, count (*) as nb FROM anyTable GROUP BY 1 nb has bigint! I think we should change the type attribute has AttributType.Object to AttributType.INTERGER What is your opinion on the subject? regards Eric -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
