julia | A lightweight high performance http server | HTTP library

It depends on what you want to test (i.e. if you want to test looping or just want the result fast). I assume you want the result fast and in a clean code, in which case I would write this operation in the following way in Julia:

To find where is Julia located try:

The original code can be re-written in the following way:

In Julia, loop bodies introduce local scopes the same as function bodies. If you assign to a variable that isn’t already a local or explicitly declared to be global, then it is, by default, a new local variable. Combining those two facts implies that assigning to i inside of the loop causes it to be a new local. On the other hand, if you don’t assign to it and only access it then it must be a variable from some outer scope, local or global, but in this case global.

Regarding the second question: a variable in a given scope can only have one meaning—it’s either local or global. It can’t be local in one part of the loop body and global in a different part (unless there’s an inner nested scope, but then that’s a different scope region). If it’s declared global anywhere, it’s global everywhere both before and after that declaration. If it’s local then it’s local everywhere.

The basic answer is that for an a = Array(T) Julia always allocates sizeof(T)*length(a)+40 bytes. Since sizeof(Missing) == 0, this means it doesn't allocate any bytes related to the length.

Indexing occurs on line 569 of array.c, and the relevant line is

Effectively what you're after is a very specific case of a circular array. You achieve that with mod1. It'll "wrap around" values outside of the valid indices. It takes two arguments; the first is the value (the index to wrap) and the second is the modulus (the length of the array). In the context of indexing, you can just use that special end syntax for the modulus:

If your matrix is symmetric use the Symmetric wrapper to improve performance (a different method is called then):

tic/toc should be fine, but it looks like the timing is being skewed by memory pre-allocation.

I can reproduce similar timings to your MATLAB example, however

• On first run (clear workspace)

  • Loop approach takes 2.08 sec
  • Vectorised approach takes 1.04 sec
  • Vectorisation saves 50% execution time

• On second run (workspace not cleared)

  • Loop approach takes 2.55 sec
  • Vectorised approach takes 0.065 sec
  • Vectorisation "saves" 97.5% execution time

My guess would be that since the loop approach explicitly creates a new matrix via zeros, the memory is reallocated from scratch on every run and you don't see the speed improvement on subsequent runs.

However, when HH remains in memory and the HH=___ line outputs a matrix of the same size, I suspect MATLAB is doing some clever memory allocation to speed up the operation.

We can prove this theory with the following test:

It is possible to do it in place like this: