Tag Info

Hot answers tagged

7

Yes. The primary problem is that the language is defined to be dynamic- that is, you never know what you're doing until you're about to do it. That makes it very hard to produce efficient machine code, because you don't know what to produce machine code for. JIT compilers can do some work in this area but it's never comparable to C++ because the JIT compiler ...


7

I kind of hit this wall myself when I took a full-time Python programming job a couple years ago. I love Python, I really do, but when I started to do some performance tuning, I had some rude shocks. The strict Pythonistas can correct me, but here are the things I found, painted in very broad strokes. Python memory usage is kind of scary. Python ...


7

The Python reference implementation is the “CPython” interpreter. It tries to be reasonably fast, but it does not currently employ advanced optimizations. And for many usage scenarios, this is a good thing: The compilation to some intermediary code happens immediately before runtime, and each time the program is executed the code is compiled anew. So the ...


6

There are three main factors that affect the performance of all dynamic languages, some more than others. Interpretive overhead. At runtime there is some kind of byte code rather than machine instructions and there is a fixed overhead to executing this code. Dispatch overhead. The target for a function call is not known until runtime, and finding out which ...


4

The inefficiency/messiness is coming from "hydrating" your data too early and too often. By "hydrating," I mean instantiating data objects from (what I assume are) records in your database. You don't always need to deal with data objects. For example, with this code... $posts = Posts::getPosts(); // get the ids into an array $post_ids = array(); ...


3

Fragment is a modular section of an Activity that has it's own lifecycle, receives its own input events, which you can add or remove while the activity is running (sort of like a "sub activity" that you can reuse in different activities) Apart from the obvious advantage of using fragments, UI optimization across different screens, it lets you manage ...


3

I see no advantages to separating the databases, and several downsides. You're forced to guess in advance what data will never change and which might change. Such guesses are virtually always wrong in some way. Additional programming and configuration overhead for dealing with two database connections rather than one. JOINs between data from the different ...


3

When you loaded the definition for your own max function into ghci, you may have not noticed that ghci indicated that it was interpreted (something along these lines): Prelude> :l mymax.hs [1 of 1] Compiling Main ( mymax.hs, interpreted ) Ok, modules loaded: Main. In order to really benchmark performance, compile your definition with ghc ...


2

What is the best way to get a grip on intended and unintended performance changes in such a setup? I don't know anything about your benchmark suite, but as far as I understand the question, this can be implemented as an automatic test (I assume you have already a test suite with integration or acceptance tests in place). What you need is a ...


2

I believe that the best approach for your case is using Jenkins with the Performance Plugin. It has nice graphs and can be used both with JMeter and SoapUI. Also test performance is important. According to Martin Fowler it is better to run fast unit tests for every commit and slow integration and performance tests every few hours.


2

I have a limited amount of experience with Jenkins. One thing I really liked about it was the dashboard display that had been set up by my colleagues, using plugins for Jira, Subversion, and Clover (code coverage). Jenkins supports quite a number of plugins and you can develop them yourself. I know that Hudson has a similar extensibility.


2

Look at the generated byte code. One obvious explanation would be that your first call to currentTimeMillis() is so obviously useless that the optimizer removed it altogether, and the second isn't. There are countless similar and less similar possible reasons, and speculating about them without looking at what's actually going on is pretty useless.


2

These stats are for the Model I, and is for two 10 digit numbers. The Model I did in fact use table look ups for math, except for divide (add table was at locations 300-399, multiply at 100-299). The Model II had circuitry for addition and subtraction, but still used table look up for multiply. As odd as all of that sounds what you would find most odd was ...


2

Your original approach does lazy loading while your modified code does eager loading. You are absolutely right that eager loading is more efficient in your situation. In most cases, minimising the number of queries is the best thing you can do to speed up your app. If you were only going to look at one of the posts then lazy loading would be faster. Most ...


1

As far as I know, it's not a common practice. Based on how much your static information is really static you can consider other options to decide where store the data, instead using a database. For example, if the static data never change you can consider to use a Constants class: public static class Constants{ public const int MyConstantValue = 10; ...


1

This is a method known as "object pooling", and you are correct that it can speed up performance. Object creation is usually a fairly inexpensive task in Javascript (though Object.create can be pretty slow surprisingly in my experience), but needing to invoke the GC repeatedly can cause noticeable performance issues. Of course, you should only optimize if ...


1

From the previous column in that table, the "1620" is the IBM 1620. https://en.wikipedia.org/wiki/IBM_1620 And yes it means multiplying two numbers.



Only top voted, non community-wiki answers of a minimum length are eligible