fix(docs): optimisation info

gitlab-pages/docs/advanced/src/optimisation/inlining_a.jsligo

@@ -0,0 +1,4 @@
+const sum = (x: int, y: int) => x + y;
+
+const main = (parameter: int, storage: int): [list<operation>, int] =>
+  [[], sum(parameter, storage)]

gitlab-pages/docs/advanced/src/optimisation/inlining_a.mligo

@@ -0,0 +1,4 @@
+let sum (x, y : int * int) = x + y
+
+let main (parameter, storage : int * int) : operation list * int =
+  ([], sum (parameter, storage))

gitlab-pages/docs/advanced/src/optimisation/inlining_b.jsligo

@@ -0,0 +1,4 @@
+const main = (_p: unit, _s: int): [list<operation>, int] => {
+  const n = 4 as int;
+  return [[], n * n];
+};

gitlab-pages/docs/advanced/src/optimisation/inlining_b.mligo

@@ -0,0 +1,3 @@
+let n = 4
+
+let main (_p, _s : unit * int) : operation list * int = [], n * n

gitlab-pages/docs/advanced/src/optimisation/lazy_entrypoints.jsligo

@@ -0,0 +1,40 @@
+type big_lambda = (p: int) => int;
+type storage_type = {
+    large_entrypoint_map: big_map<bool, big_lambda>;
+    value: int
+  }
+type return_type = [list<operation>, storage_type];
+
+class LazyEntrypoint {
+
+  // Get the code from the big-map
+  static load_large_ep = (storage: storage_type): big_lambda => {
+    const large_entrypoint_opt =
+      Big_map.find_opt(true, storage.large_entrypoint_map);
+    return $match(large_entrypoint_opt, {
+      "Some": ep => ep,
+      "None": () => failwith("Internal error"),
+    });
+  }
+
+  // Run the code from the big-map
+  @entry
+  static large_entry_point = (param: int, storage: storage_type): return_type => {
+    const newValue = load_large_ep(storage)(param);
+    return [[], {
+      large_entrypoint_map: storage.large_entrypoint_map,
+      value: newValue,
+      }];
+  }
+
+  // Do something that doesn't require the large code
+  @entry
+  static sub = (value: int, storage: storage_type): return_type =>
+    [[], {
+      large_entrypoint_map: storage.large_entrypoint_map,
+      value: value,
+      }];
+
+  // Other entrypoints...
+
+}

gitlab-pages/docs/advanced/src/optimisation/lazy_entrypoints.mligo

@@ -0,0 +1,28 @@
+module LazyEntrypoint = struct
+  type storage_type = {
+    large_entrypoint_map : (bool, int -> int) big_map;
+    value : int
+  }
+  type return_type = operation list * storage_type
+
+  (* Load the code from the big-map *)
+  let load_large_ep (storage : storage_type) : (int -> int) =
+    let large_entrypoint_opt =
+      Big_map.find_opt true storage.large_entrypoint_map in
+    match large_entrypoint_opt with
+      Some ep -> ep
+    | None -> failwith "Internal error"
+
+  (* Run the code from the big-map *)
+  [@entry]
+  let large_entry_point (param : int) (storage : storage_type) : return_type =
+    [], {storage with value = (load_large_ep storage) param}
+
+  (* Do something that doesn't require the large code *)
+  [@entry]
+  let small_entry_point (param : int) (storage : storage_type) : return_type =
+    [], {storage with value = param}
+
+  (* Other entrypoints... *)
+
+end

gitlab-pages/docs/intro/ligo-intro.md

@@ -49,7 +49,7 @@ A significant advantage of the multi-syntax feature is to share knowledge, tooli
 Unlike desktop, mobile, or web application development, smart
 contracts cannot rely on cheap CPU time and memory.  All resources
 contracts use are expensive and tracked as
-['gas costs'](../tutorials/optimisation/#tezos-gas-model).
+['gas costs'](../advanced/optimisation/#tezos-gas-model).
 
 The LIGO compiler generates optimised Michelson code, which will
 be cost-effective on Tezos.

gitlab-pages/docs/syntax/contracts/dynamic-entrypoints.md

@@ -16,6 +16,8 @@ If you want a client or other contract to be able to call a dynamic entrypoint,
 
 :::
 
+As described in [Optimisation](../../advanced/optimisation.md), using dynamic entrypoints can help reduce gas costs by storing complex code where it is not loaded every time the contract is called.
+
 A contract with dynamic entrypoints must have at least one non-dynamic entrypoint with the `@entry` declaration, like any other contract.
 They must also obey the following convention on storage type definition and have at least one function with the `@dyn_entry` declaration.
 

gitlab-pages/docs/tutorials/tz-vs-eth/tz-vs-eth.md

@@ -620,7 +620,7 @@ Fee model in Tezos is more complicated than the Ethereum one. The most important
 2. When you call a contract, the transaction spends gas for reading, deserialising and type-checking the storage. Also, a certain amount of gas gets spent for serialising and writing the storage back to the context. In practice, it means that **the larger your code and storage are, the more expensive it is to call your contract,** regardless of the number of computations performed. If you have big or unbounded containers in storage, you should most probably use `big_map`.
 3. Emitting internal operations is very expensive in terms of gas: there is a fixed cost of 10000 gas for `Tezos.get_{contract, entrypoint}_opt` plus the cost of reading, deserialising, and type-checking the parameter of the callee.
 
-Always test for gas consumption and strive to minimise the size of the data stored on chain and the number of internal operations emitted. You can read more on fees in our [Optimisation guide](../optimisation/optimisation.md) or in the [Serokell blog post](https://medium.com/tqtezos/how-to-minimize-transaction-costs-of-tezos-smart-contracts-9962347faf64).
+Always test for gas consumption and strive to minimise the size of the data stored on chain and the number of internal operations emitted. You can read more on fees in [Optimisation](../advanced/optimisation) or in the [Serokell blog post](https://medium.com/tqtezos/how-to-minimize-transaction-costs-of-tezos-smart-contracts-9962347faf64).
 
 ## Conclusion
 

gitlab-pages/website/sidebars.js

@@ -136,8 +136,8 @@ const sidebars = {
     ],
     "Advanced Topics": [
       "advanced/package-management",
-      "tutorials/optimisation/optimisation",
-      "advanced/security"
+      "advanced/optimisation",
+      "advanced/security",
     ]
   },
   "API": {