As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Simple enough really. I have a horrible amount of JSON to process, 100GB in total. This 100GB is split into files which are typically 1mb each.
So this left me wondering, typically speaking would it be quicker to parse a JSON file in Javascript or would I have similar results processing the file using one of Java's JSON jars?
Now obviously I'd have to multi thread all of this and so on.
Use whatever technology you're most adept at, the odds of a massive performance difference are low. V8 (Google's JavaScript engine — best known in the Chrome browser, and in NodeJS in non-browser environments, but which can also be run standalone) is freaky fast, as is Sun/Oracle's JVM with its excellent hotspot optimization technology. You could even use JavaScript on the JVM if you like (Rhino).
Now obviously I'd have to multi thread all of this and so on.
It's not obvious at all. If the process is I/O bound (and if you're reading a thousand 100MB files, it sounds like it probably will be, depending on what you're doing with them), adding multiple threads won't help you.
i think it'd be easier, faster, and more easily scalable (ThreadPoolExecutor) to process in java.
how were you planning to do it with javascript? stand alone v8 ?
If you know it, I'd use Node.js. Better to handle JSON objects in an environment built on Javascript
Both languages are run in a virtual execution environement so the execution speed will the more dependent on the VM you use and recent VMs have become really fast especially on recent hardware.
To my knowledge, javascript doesn't have 'native' support for threading. Multithreading was implemented in a "time shared" execution to prevent lockups. This seems however to no longer be the case with "webworkers" Also you could just split your files across different processes that will independently process the files this will however generate a lot of concurrent disk access which will most probably be your bottleneck when processing your files.
So I'd suggest you go with the language that you are the most comfortable with.
Btw. mind telling us what kind of processing you will be doing on the json files ?
If I were to implement this: to limit concurrent IO, I'd have a 1st thread that will prefetch one file at a time and read it into memory and queue a worker to process that file (if the processing is heavy a threadpool will certainly improve processing speed).
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I need to call a method from another JVM running on the same machine. This methods needs to be called very many time with Java/native-like performance. It is a small-input small-output method. The other JVM runs on the same machine.
What is the fastest way to make this call and retrieve the result from this other JVM running "nearby"?
Some options are probably RMI, pipes, sockets, JMS, an optimized same-machine inter-JVM communication support, some low-level hack in the JVM. Any idea is welcome, regardless of how specialized it is.
The fastest way to communicate between JVMs on the same machine is using shared memory e.g. via memory mapped files. This is as much as 100x faster than using a Socket over loopback. e.g. a 200 ns round trip time vs a 10-20 micro-second round trip time for Sockets.
One implementation is Java Chronicle BTW The 100 ns latency includes persistence of the messages.
Whether you need either of these solutions isn't something you should take for granted. Often when people say they have to have the "fastest" they really mean they don't know how fast it needs to be so if they pick the fastest it should be the right solution. This is usually not correct because taking the fastest solution often means making compromises in the design and implementation which it may turn were never needed if only you knew what the requirements really were.
In short, unless you have specific, measurable latency and/or throughput requirements you should assume that the simplest solution is what you really want. This can be replaced with something faster should it turn out it is not suitable when you have a better understanding of what is required.
Another possibility is 0MQ (ZeroMQ), though it depends what you mean by "fastest" - zeromq is excellent for throughput but if you absolutely must have the lowest possible latency it may not be optimal.
ZeroMQ may be overkill for just two JVMs, but has the advantage that if you later want to move one of the JVMs to another machine, or communicate with non-Java processes, ZeroMQ will still work just fine - and it scales to larger-scale, more complex communications too.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
It's not going to be a request for general comparisson:
Play! framework is Java based which means the code is interpreted to bytecode and then compiled by the JVM in runtime. On the other hand, Ruby is a dynamic language which means the code is interpreted with every request. This is certainly obvious for every programmer.
Another aspect is the development process and the ease of the language (strong typing vs weak typing).
Currently I'm developing a new website using Play!
So, for the questions:
Performance for an HTTP server (Play! runs on the JVM, Ruby is dynamic) - does it really matter for a website? would you see a significant differences?
I feel RoR has much larger community, sources, tutorials etc, and it's a little batter me. Or should it?
Well, it depends.
Ruby's not a particularly fast language, but language execution speed is likely not to be your bottleneck—in my experience, ruby's relative slowness is often just a drop in the ocean of external service calls (e.g. databases), algorithmic problems (e.g. synchronous, blocking subroutines), and design choices that are just generally inappropriate for the problem domain. Keep your whole technology stack in perspective.
Community's important, and Ruby/Rails has an extremely active one. AFAIK Play's smaller, but in my own experience Java and Scala (and the myriad other languages that have JVM implementations (including Ruby)) also have good communities.
All of this depends on the specific needs of your app (and you!). If Ruby's too slow, it's too slow. If you absolutely need some library that only exists in Java, use Java. Choose the tool to fit the task. But keep the entire task (and your own needs for completing that task) in perspective.
Many differences between these two models. As for the performance, my opinion about Java based & RoR:
1, Java based website(running on several Java Application Servers), has its unique advantage, such as multi-thread model(highest speed to read local data), global memory, easy to pooling resources, plenty of efficient clients to connect all kinds of 3rd part OSS tools...
2, RoR (and Php) model of HTTPServer connection, need to "proxy" request to App tier. Multi-process model increases inter-process communications. And as a "dynamic language", the performance is lower.
But, nowadays, web programming depends on other tools to boost up. The widespread uses of cache, NoSQL(Memcached, Redis, TT/TC), IPC/RPC framework(netty, akka, )... shift the bottleneck. I knew both above models has been used in large-scale networking social games.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been doing software development (in Java) since 1998 and have worked with many different teams solving various different problems. Never during time period has any team used parallel programming methods. Even though multi-core processors have been around for a while, I find that parallel programming models are still largely ignored in the real world to solve problems. So, why is parallel programming not used more often? It seems like a good way to make things more scalable, efficient and generally improve performance of programs.
Because getting parallel programming right in a multithreaded shared-memory environment like Java is really, really hard. You're practically guaranteed to make mistakes that are very hard to diagnose. And of course it's extra effort.
Furthermore, the kind of programs that most people work on are workflow systems. Desktop versions of those aren't performance-critical, and webapps / server components are trivial to parallelize by having each request be served by its own thread. This has the advantage that developers don't really have to deal with the parallel aspect.
Because parallel programming is not applicable to every possible problem and because writing a correct concurrent program is hard. Especially making sure that threads are synchronized correctly without unnecessary locking is just not easy. Also, bugs that happen depending on the timing of thread scheduling are very hard to reproduce, find and fix. It's very nasty if you have a concurrency bug that happens once every 100,000 transactions and it happens on production and not on your development system (I've been there...).
Read the book Java Concurrency in Practice, the best book about concurrent programming in Java.
parallel programming models are still largely ignored in the real world to solve problems
I think it is being used where it solves problems. But it doesn't come for free, so it's indeed better not to do anything in parallel (asynchronously) when a simpler serial (synchronous) solution works well enough.
Real parallel programming (where you split up a problem over several cores) is mostly interesting for long running algorithms. Most real life applications are more event processors. Often these events will run in parallel (think about a web server having several threads to process requests). when programming is used to solve an arithmetic problem, it is used more often (think optimization, data analysis etc)
I think your opinion is wrong, for sample when you are have a server side application, application server handle any request by a thread(maybe achieve it from thread-pool).
I guess any place that need to parallel(multi-threading) model you have to do programming parallel.
There is usefull information in following link :
http://www.asjava.com/core-java/why-we-need-to-use-multiple-threads/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm interested in learning a dynamic language after at least 10 years on the Java platform. There are two choices that I was considering. One, learning one such as Clojure / Groovy that ride on top of the Java JVM. Secondly, a language off the JVM, which would include Ruby / Rails or Erlang.
Having knowing alot about the Java side, I'd like to choose a JVM based solution, but considering an off the JVM solution.
My question is:
What advantages / disadvantages would I get by choosing a language off of the Java JVM?
One of my biggest pain points is deployment memory footprint. I'd like to have a solution that allows low memory consumption, because most cloud / ISP providers require high dollar for anything greater the 512 MB / server. I've been so used to using High Memory JVM's which just don't work well with my costs. Maybe this isn't a concern for using clojure or groovy, but I'd expect a high memory footprint since it's running on the JVM.
I've already started using Ruby / Rails lately and I've been impressed with it.
If you go off the JVM then you have a good tool you can use in the cases where the JVM is poorly suited, like command line utilities where JVM startup time is really annoying.
If you go with Clojure you get both, with the clojure compiler you can produce classes for the JVM and with the ClojureScript compiler you can produce javascript that will run on very nearly anything.
My personal and therefore unverifiable advice is to go with the option that will expand your programming mind cough clojure but I am personally rather biased.
You could try JRuby to support ruby on and off a JVM.
I wouldn't assume that using JVM means using lots of memory. This depends on how you use the JVM. Using a profiler and more compact data structures can minimise memory usage. You can look at using C++, but if you are not careful C++ can use more memory. (But not if you know what you are doing)
How much memory you use is more about how you develop your program than which language you use.
For a low footprint solution, you may wish to consider JavaScript coupled with the V8 JS engine and Node.js technology
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Which language is faster for web, Java or PHP?
It is a difficult one to answer as in theory Java should be faster:
it's precompiled, any trivial algorithim will run faster in Java than PHP and there has been a vast amount of work done to optimise Java from improving the code, standard libraries, to JIT compilers, etc.
PHP is loaded and interpreted every time if you're not using the Zend optimiser, objects are intialised on every execution, even the most trivial string varaible is actually a complex object with many methods to support.
The problem is that in practice PHP sites seem to run faster using fewer resources.
I think this is because PHP developers take a more straightforward approach to design and don't get lost trying to implement exotic design patterns and implementing endless pointless abstractions.
Speed doesn't matter
in most cases.
Processing is cheap. Code in what you're comfortable with. Writing proper code goes much further for speed then choosing a language. Solid coding conventions and design plan will also help more.
Best answer I could find
"stuff to consider:
Java web applications are compiled
to bytecode. Even JSPs, which are
compiled at runtime. This is an
advantage over most uses of PHP,
where the Zend Optimizer is not in
use.
Data can be cached in a live servlet
instance - no direct/easy way of
doing this in PHP to my knowledge
(there is only ever a single
instance of a servlet/JSP in memory)
If anybody knows how to cache data in PHP without resorting to ugly
hacks, please enlighten me!
Java applications tend to be
n-tiered, which generally results in
a more maintainable application at a
slight performance penalty. This
probably sounds trollish, but
honestly: even within Java itself
direct use of JDBC will always be
faster than going through three
layers of objects to the database.
But is an n-tiered Java application able to hit the database sooner than an uncompiled, hacked-up monolithic PHP script? I don't think there's an answer to that question.
All that said, I'm working on an n-tiered MVC framework for php 5 (it's called Pure (http://www.sf.net/projects/php-pure)), so my PHP applications are generally n-tiered too. I'll worry about speed when and if it becomes an issue. For now, it's definitely not an issue."
courtesy of krumms
Speed aside, I believe the performance of Java is better than PHP. But developing a project in PHP is faster.
Can't answer this question with one or the other unless you define what you want to measure the speed of.
Some things are much faster in PHP (in a native function for example), other things are much faster in Java.
The intent of each language is substantially different from the other, so if you're debating over which to use for a particular task, you should generally based the decision on that task (and how well suited each language is to it) rather than performance.
For raw performance of code written in the language (as opposed to simply calling code in the standard library), Java will probably run faster than PHP as an extremely general rule. If that matters, chances are that PHP just isn't very well suited to the task at hand.